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

[Linux-stable-mirror] Patch "RDS: RDMA: return appropriate error on rdma map failures" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled RDS: RDMA: return appropriate error on rdma map failures to the 3.18-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: rds-rdma-return-appropriate-error-on-rdma-map-failures.patch and it can be found in the queue-3.18 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 Tue Nov 28 10:58:31 CET 2017 From: Santosh Shilimkar <santosh.shilimkar(a)oracle.com> Date: Mon, 4 Jul 2016 17:04:37 -0700 Subject: RDS: RDMA: return appropriate error on rdma map failures From: Santosh Shilimkar <santosh.shilimkar(a)oracle.com> [ Upstream commit 584a8279a44a800dea5a5c1e9d53a002e03016b4 ] The first message to a remote node should prompt a new connection even if it is RDMA operation. For RDMA operation the MR mapping can fail because connections is not yet up. Since the connection establishment is asynchronous, we make sure the map failure because of unavailable connection reach to the user by appropriate error code. Before returning to the user, lets trigger the connection so that its ready for the next retry. Signed-off-by: Santosh Shilimkar <santosh.shilimkar(a)oracle.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/rds/send.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) --- a/net/rds/send.c +++ b/net/rds/send.c @@ -903,6 +903,11 @@ static int rds_cmsg_send(struct rds_sock ret = rds_cmsg_rdma_map(rs, rm, cmsg); if (!ret) *allocated_mr = 1; + else if (ret == -ENODEV) + /* Accommodate the get_mr() case which can fail + * if connection isn't established yet. + */ + ret = -EAGAIN; break; case RDS_CMSG_ATOMIC_CSWP: case RDS_CMSG_ATOMIC_FADD: @@ -1011,8 +1016,12 @@ int rds_sendmsg(struct kiocb *iocb, stru /* Parse any control messages the user may have included. */ ret = rds_cmsg_send(rs, rm, msg, &allocated_mr); - if (ret) + if (ret) { + /* Trigger connection so that its ready for the next retry */ + if (ret == -EAGAIN) + rds_conn_connect_if_down(conn); goto out; + } if (rm->rdma.op_active && !conn->c_trans->xmit_rdma) { printk_ratelimited(KERN_NOTICE "rdma_op %p conn xmit_rdma %p\n", Patches currently in stable-queue which might be from santosh.shilimkar(a)oracle.com are queue-3.18/rds-rdma-return-appropriate-error-on-rdma-map-failures.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "PCI: Apply _HPX settings only to relevant devices" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled PCI: Apply _HPX settings only to relevant devices to the 3.18-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: pci-apply-_hpx-settings-only-to-relevant-devices.patch and it can be found in the queue-3.18 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 Tue Nov 28 10:58:31 CET 2017 From: Bjorn Helgaas <bhelgaas(a)google.com> Date: Mon, 2 Jan 2017 14:04:24 -0600 Subject: PCI: Apply _HPX settings only to relevant devices From: Bjorn Helgaas <bhelgaas(a)google.com> [ Upstream commit 977509f7c5c6fb992ffcdf4291051af343b91645 ] Previously we didn't check the type of device before trying to apply Type 1 (PCI-X) or Type 2 (PCIe) Setting Records from _HPX. We don't support PCI-X Setting Records, so this was harmless, but the warning was useless. We do support PCIe Setting Records, and we didn't check whether a device was PCIe before applying settings. I don't think anything bad happened on non-PCIe devices because pcie_capability_clear_and_set_word(), pcie_cap_has_lnkctl(), etc., would fail before doing any harm. But it's ugly to depend on those internals. Check the device type before attempting to apply Type 1 and Type 2 Setting Records (Type 0 records are applicable to PCI, PCI-X, and PCIe devices). A side benefit is that this prevents useless "not supported" warnings when a BIOS supplies a Type 1 (PCI-X) Setting Record and we try to apply it to every single device: pci 0000:00:00.0: PCI-X settings not supported After this patch, we'll get the warning only when a BIOS supplies a Type 1 record and we have a PCI-X device to which it should be applied. Link: https://bugzilla.kernel.org/show_bug.cgi?id=187731 Signed-off-by: Bjorn Helgaas <bhelgaas(a)google.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/pci/probe.c | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-) --- a/drivers/pci/probe.c +++ b/drivers/pci/probe.c @@ -1329,8 +1329,16 @@ static void program_hpp_type0(struct pci static void program_hpp_type1(struct pci_dev *dev, struct hpp_type1 *hpp) { - if (hpp) - dev_warn(&dev->dev, "PCI-X settings not supported\n"); + int pos; + + if (!hpp) + return; + + pos = pci_find_capability(dev, PCI_CAP_ID_PCIX); + if (!pos) + return; + + dev_warn(&dev->dev, "PCI-X settings not supported\n"); } static void program_hpp_type2(struct pci_dev *dev, struct hpp_type2 *hpp) @@ -1341,6 +1349,9 @@ static void program_hpp_type2(struct pci if (!hpp) return; + if (!pci_is_pcie(dev)) + return; + if (hpp->revision > 1) { dev_warn(&dev->dev, "PCIe settings rev %d not supported\n", hpp->revision); Patches currently in stable-queue which might be from bhelgaas(a)google.com are queue-3.18/pci-apply-_hpx-settings-only-to-relevant-devices.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "netfilter: nft_queue: use raw_smp_processor_id()" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled netfilter: nft_queue: use raw_smp_processor_id() to the 3.18-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: netfilter-nft_queue-use-raw_smp_processor_id.patch and it can be found in the queue-3.18 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 Tue Nov 28 10:58:31 CET 2017 From: Pablo Neira Ayuso <pablo(a)netfilter.org> Date: Sun, 11 Dec 2016 20:46:51 +0100 Subject: netfilter: nft_queue: use raw_smp_processor_id() From: Pablo Neira Ayuso <pablo(a)netfilter.org> [ Upstream commit c2e756ff9e699865d294cdc112acfc36419cf5cc ] Using smp_processor_id() causes splats with PREEMPT_RCU: [19379.552780] BUG: using smp_processor_id() in preemptible [00000000] code: ping/32389 [19379.552793] caller is debug_smp_processor_id+0x17/0x19 [...] [19379.552823] Call Trace: [19379.552832] [<ffffffff81274e9e>] dump_stack+0x67/0x90 [19379.552837] [<ffffffff8129a4d4>] check_preemption_disabled+0xe5/0xf5 [19379.552842] [<ffffffff8129a4fb>] debug_smp_processor_id+0x17/0x19 [19379.552849] [<ffffffffa07c42dd>] nft_queue_eval+0x35/0x20c [nft_queue] No need to disable preemption since we only fetch the numeric value, so let's use raw_smp_processor_id() instead. Signed-off-by: Pablo Neira Ayuso <pablo(a)netfilter.org> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/netfilter/nft_queue.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/net/netfilter/nft_queue.c +++ b/net/netfilter/nft_queue.c @@ -37,7 +37,7 @@ static void nft_queue_eval(const struct if (priv->queues_total > 1) { if (priv->flags & NFT_QUEUE_FLAG_CPU_FANOUT) { - int cpu = smp_processor_id(); + int cpu = raw_smp_processor_id(); queue = priv->queuenum + cpu % priv->queues_total; } else { Patches currently in stable-queue which might be from pablo(a)netfilter.org are queue-3.18/netfilter-nf_tables-fix-oob-access.patch queue-3.18/netfilter-nft_queue-use-raw_smp_processor_id.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "netfilter: nf_tables: fix oob access" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled netfilter: nf_tables: fix oob access to the 3.18-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: netfilter-nf_tables-fix-oob-access.patch and it can be found in the queue-3.18 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 Tue Nov 28 10:58:31 CET 2017 From: Florian Westphal <fw(a)strlen.de> Date: Tue, 13 Dec 2016 13:59:33 +0100 Subject: netfilter: nf_tables: fix oob access From: Florian Westphal <fw(a)strlen.de> [ Upstream commit 3e38df136e453aa69eb4472108ebce2fb00b1ba6 ] BUG: KASAN: slab-out-of-bounds in nf_tables_rule_destroy+0xf1/0x130 at addr ffff88006a4c35c8 Read of size 8 by task nft/1607 When we've destroyed last valid expr, nft_expr_next() returns an invalid expr. We must not dereference it unless it passes != nft_expr_last() check. Signed-off-by: Florian Westphal <fw(a)strlen.de> Signed-off-by: Pablo Neira Ayuso <pablo(a)netfilter.org> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/netfilter/nf_tables_api.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/net/netfilter/nf_tables_api.c +++ b/net/netfilter/nf_tables_api.c @@ -1869,7 +1869,7 @@ static void nf_tables_rule_destroy(const * is called on error from nf_tables_newrule(). */ expr = nft_expr_first(rule); - while (expr->ops && expr != nft_expr_last(rule)) { + while (expr != nft_expr_last(rule) && expr->ops) { nf_tables_expr_destroy(ctx, expr); expr = nft_expr_next(expr); } Patches currently in stable-queue which might be from fw(a)strlen.de are queue-3.18/netfilter-nf_tables-fix-oob-access.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "net: 3com: typhoon: typhoon_init_one: make return values more specific" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled net: 3com: typhoon: typhoon_init_one: make return values more specific to the 3.18-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: net-3com-typhoon-typhoon_init_one-make-return-values-more-specific.patch and it can be found in the queue-3.18 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 Tue Nov 28 10:58:31 CET 2017 From: Thomas Preisner <thomas.preisner+linux(a)fau.de> Date: Fri, 30 Dec 2016 03:37:54 +0100 Subject: net: 3com: typhoon: typhoon_init_one: make return values more specific From: Thomas Preisner <thomas.preisner+linux(a)fau.de> [ Upstream commit 6b6bbb5922a4b1d4b58125a572da91010295fba3 ] In some cases the return value of a failing function is not being used and the function typhoon_init_one() returns another negative error code instead. Signed-off-by: Thomas Preisner <thomas.preisner+linux(a)fau.de> Signed-off-by: Milan Stephan <milan.stephan+linux(a)fau.de> 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/3com/typhoon.c | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) --- a/drivers/net/ethernet/3com/typhoon.c +++ b/drivers/net/ethernet/3com/typhoon.c @@ -2366,9 +2366,9 @@ typhoon_init_one(struct pci_dev *pdev, c * 4) Get the hardware address. * 5) Put the card to sleep. */ - if (typhoon_reset(ioaddr, WaitSleep) < 0) { + err = typhoon_reset(ioaddr, WaitSleep); + if (err < 0) { err_msg = "could not reset 3XP"; - err = -EIO; goto error_out_dma; } @@ -2382,16 +2382,16 @@ typhoon_init_one(struct pci_dev *pdev, c typhoon_init_interface(tp); typhoon_init_rings(tp); - if(typhoon_boot_3XP(tp, TYPHOON_STATUS_WAITING_FOR_HOST) < 0) { + err = typhoon_boot_3XP(tp, TYPHOON_STATUS_WAITING_FOR_HOST); + if (err < 0) { err_msg = "cannot boot 3XP sleep image"; - err = -EIO; goto error_out_reset; } INIT_COMMAND_WITH_RESPONSE(&xp_cmd, TYPHOON_CMD_READ_MAC_ADDRESS); - if(typhoon_issue_command(tp, 1, &xp_cmd, 1, xp_resp) < 0) { + err = typhoon_issue_command(tp, 1, &xp_cmd, 1, xp_resp); + if (err < 0) { err_msg = "cannot read MAC address"; - err = -EIO; goto error_out_reset; } @@ -2424,9 +2424,9 @@ typhoon_init_one(struct pci_dev *pdev, c if(xp_resp[0].numDesc != 0) tp->capabilities |= TYPHOON_WAKEUP_NEEDS_RESET; - if(typhoon_sleep(tp, PCI_D3hot, 0) < 0) { + err = typhoon_sleep(tp, PCI_D3hot, 0); + if (err < 0) { err_msg = "cannot put adapter to sleep"; - err = -EIO; goto error_out_reset; } Patches currently in stable-queue which might be from thomas.preisner+linux(a)fau.de are queue-3.18/net-3com-typhoon-typhoon_init_one-fix-incorrect-return-values.patch queue-3.18/net-3com-typhoon-typhoon_init_one-make-return-values-more-specific.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "net: 3com: typhoon: typhoon_init_one: fix incorrect return values" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled net: 3com: typhoon: typhoon_init_one: fix incorrect return values to the 3.18-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: net-3com-typhoon-typhoon_init_one-fix-incorrect-return-values.patch and it can be found in the queue-3.18 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 Tue Nov 28 10:58:31 CET 2017 From: Thomas Preisner <thomas.preisner+linux(a)fau.de> Date: Fri, 30 Dec 2016 03:37:53 +0100 Subject: net: 3com: typhoon: typhoon_init_one: fix incorrect return values From: Thomas Preisner <thomas.preisner+linux(a)fau.de> [ Upstream commit 107fded7bf616ad6f46823d98b8ed6405d7adf2d ] In a few cases the err-variable is not set to a negative error code if a function call in typhoon_init_one() fails and thus 0 is returned instead. It may be better to set err to the appropriate negative error code before returning. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=188841 Reported-by: Pan Bian <bianpan2016(a)163.com> Signed-off-by: Thomas Preisner <thomas.preisner+linux(a)fau.de> Signed-off-by: Milan Stephan <milan.stephan+linux(a)fau.de> 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/3com/typhoon.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) --- a/drivers/net/ethernet/3com/typhoon.c +++ b/drivers/net/ethernet/3com/typhoon.c @@ -2398,8 +2398,9 @@ typhoon_init_one(struct pci_dev *pdev, c *(__be16 *)&dev->dev_addr[0] = htons(le16_to_cpu(xp_resp[0].parm1)); *(__be32 *)&dev->dev_addr[2] = htonl(le32_to_cpu(xp_resp[0].parm2)); - if(!is_valid_ether_addr(dev->dev_addr)) { + if (!is_valid_ether_addr(dev->dev_addr)) { err_msg = "Could not obtain valid ethernet address, aborting"; + err = -EIO; goto error_out_reset; } @@ -2407,7 +2408,8 @@ typhoon_init_one(struct pci_dev *pdev, c * later when we print out the version reported. */ INIT_COMMAND_WITH_RESPONSE(&xp_cmd, TYPHOON_CMD_READ_VERSIONS); - if(typhoon_issue_command(tp, 1, &xp_cmd, 3, xp_resp) < 0) { + err = typhoon_issue_command(tp, 1, &xp_cmd, 3, xp_resp); + if (err < 0) { err_msg = "Could not get Sleep Image version"; goto error_out_reset; } @@ -2449,7 +2451,8 @@ typhoon_init_one(struct pci_dev *pdev, c dev->features = dev->hw_features | NETIF_F_HW_VLAN_CTAG_RX | NETIF_F_RXCSUM; - if(register_netdev(dev) < 0) { + err = register_netdev(dev); + if (err < 0) { err_msg = "unable to register netdev"; goto error_out_reset; } Patches currently in stable-queue which might be from thomas.preisner+linux(a)fau.de are queue-3.18/net-3com-typhoon-typhoon_init_one-fix-incorrect-return-values.patch queue-3.18/net-3com-typhoon-typhoon_init_one-make-return-values-more-specific.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] [GIT PULL] commits for Linux 3.18

by alexander.levin＠verizon.com

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi Greg, Pleae pull commits for Linux 3.18 . I've sent a review request for all commits over a week ago and all comments were addressed. Thanks, Sasha ===== The following changes since commit 7166ceea0a4eba3f8c86925ad60e6f0543db6234: Linux 3.18.84 (2017-11-24 08:30:05 +0100) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/sashal/linux-stable.git for-greg-3.18-2 for you to fetch changes up to d140a493dcb8c85a96b97318d269a67f20df773f: xen: xenbus driver must not accept invalid transaction ids (2017-11-24 10:53:28 -0500) - ---------------------------------------------------------------- Bjorn Helgaas (1): PCI: Apply _HPX settings only to relevant devices Daniel Vetter (1): drm/armada: Fix compile fail Florian Westphal (1): netfilter: nf_tables: fix oob access Gabriele Mazzotta (1): ALSA: hda - Apply ALC269_FIXUP_NO_SHUTUP on HDA_FIXUP_ACT_PROBE Heiko Carstens (1): s390/kbuild: enable modversions for symbols exported from asm Juergen Gross (1): xen: xenbus driver must not accept invalid transaction ids Masashi Honma (2): mac80211: Remove invalid flag operations in mesh TSF synchronization mac80211: Suppress NEW_PEER_CANDIDATE event if no room Pablo Neira Ayuso (1): netfilter: nft_queue: use raw_smp_processor_id() Pan Bian (2): staging: iio: cdc: fix improper return value btrfs: return the actual error value from from btrfs_uuid_tree_iterate Richard Fitzgerald (1): ASoC: wm_adsp: Don't overrun firmware file buffer when reading region data Santosh Shilimkar (1): RDS: RDMA: return appropriate error on rdma map failures Thomas Preisner (2): net: 3com: typhoon: typhoon_init_one: make return values more specific net: 3com: typhoon: typhoon_init_one: fix incorrect return values arch/s390/include/asm/asm-prototypes.h | 8 ++++++++ drivers/gpu/drm/armada/Makefile | 2 ++ drivers/net/ethernet/3com/typhoon.c | 25 ++++++++++++++----------- drivers/pci/probe.c | 15 +++++++++++++-- drivers/staging/iio/cdc/ad7150.c | 2 +- drivers/xen/xenbus/xenbus_dev_frontend.c | 2 +- fs/btrfs/uuid-tree.c | 4 +--- net/mac80211/ieee80211_i.h | 1 - net/mac80211/mesh.c | 3 --- net/mac80211/mesh_plink.c | 14 ++++++++------ net/mac80211/mesh_sync.c | 11 ----------- net/netfilter/nf_tables_api.c | 2 +- net/netfilter/nft_queue.c | 2 +- net/rds/send.c | 11 ++++++++++- sound/pci/hda/patch_realtek.c | 2 +- sound/soc/codecs/wm_adsp.c | 25 ++++++++++++++++++++++++- 16 files changed, 85 insertions(+), 44 deletions(-) create mode 100644 arch/s390/include/asm/asm-prototypes.h -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJaGFN3AAoJEN6mb/eXdyzcOXsP/1Uar5gqz6/0IwAskr3H37Wj zVQo8VcKxRIvPeB6nr/FWFp7Yx2FA+FpA/HkR/y33Byyui0Q5a704JsBvPrS3P7z GTEzEEuxMxSxfg6xBPxpex/HcblOX3KAVKgbLlBYym++Ur8E5g7xja+Di1DOtYUN 6WtBv4J/eOINLrqVnV6vkxdBP0tre7NVcSv6Tcr7Kx4tHrZwmn2uECxn0GpQ4rEr 24WnTaIroBA7W7yANuez72X3GG3PdrpX/k9fmr0Is0EPhGGnow00sY8NDPV3fUWx ycNARvS2cDL/hzNyWk+b34eGnpH+JHhelouWM+wUxtNHEYHtXCCoD/sPYJ9GBq24 OcUieoyQjV1OtECN2/fA8zRhipiJ4T8OXUAxE/gInBEoNAJ47acA62oESEGoTk1h 2j805GYJYm7ckydIms1JSw1KtccPK3KMAz2KhFdzmY5xislFidkQYee5TmCEU54z zQRKYOWff+pgV5UC1t9rU+NwmlhWW7RJoGFMi7NMKxNP7xeAByEtuha4cq9Zna88 +H2/13T8QDjcHgkOGFPGWI9z2PJwzh/qGUPWmT/VUdAY1isBa1qqYw4/hz61D6ge 3s8UaOy9/fNV7mFhPKDMjKHDL3/M7hTPXzmk+tB1NookrdrmxQDxJ2cinvKxm7xa +HfblLM3g97Rz+FcVYzq =41fD -----END PGP SIGNATURE-----

7 years, 5 months

2
1
0 0

[Linux-stable-mirror] Patch "mac80211: Suppress NEW_PEER_CANDIDATE event if no room" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled mac80211: Suppress NEW_PEER_CANDIDATE event if no room to the 3.18-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: mac80211-suppress-new_peer_candidate-event-if-no-room.patch and it can be found in the queue-3.18 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 Tue Nov 28 10:58:31 CET 2017 From: Masashi Honma <masashi.honma(a)gmail.com> Date: Wed, 30 Nov 2016 09:06:04 +0900 Subject: mac80211: Suppress NEW_PEER_CANDIDATE event if no room From: Masashi Honma <masashi.honma(a)gmail.com> [ Upstream commit 11197d006bcfabf0173a7820a163fcaac420d10e ] Previously, kernel sends NEW_PEER_CANDIDATE event to user land even if the found peer does not have any room to accept other peer. This causes continuous connection trials. Signed-off-by: Masashi Honma <masashi.honma(a)gmail.com> Signed-off-by: Johannes Berg <johannes.berg(a)intel.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/mac80211/mesh_plink.c | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) --- a/net/mac80211/mesh_plink.c +++ b/net/mac80211/mesh_plink.c @@ -448,12 +448,14 @@ mesh_sta_info_alloc(struct ieee80211_sub /* Userspace handles station allocation */ if (sdata->u.mesh.user_mpm || - sdata->u.mesh.security & IEEE80211_MESH_SEC_AUTHED) - cfg80211_notify_new_peer_candidate(sdata->dev, addr, - elems->ie_start, - elems->total_len, - GFP_KERNEL); - else + sdata->u.mesh.security & IEEE80211_MESH_SEC_AUTHED) { + if (mesh_peer_accepts_plinks(elems) && + mesh_plink_availables(sdata)) + cfg80211_notify_new_peer_candidate(sdata->dev, addr, + elems->ie_start, + elems->total_len, + GFP_KERNEL); + } else sta = __mesh_sta_info_alloc(sdata, addr); return sta; Patches currently in stable-queue which might be from masashi.honma(a)gmail.com are queue-3.18/mac80211-suppress-new_peer_candidate-event-if-no-room.patch queue-3.18/mac80211-remove-invalid-flag-operations-in-mesh-tsf-synchronization.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "mac80211: Remove invalid flag operations in mesh TSF synchronization" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled mac80211: Remove invalid flag operations in mesh TSF synchronization to the 3.18-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: mac80211-remove-invalid-flag-operations-in-mesh-tsf-synchronization.patch and it can be found in the queue-3.18 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 Tue Nov 28 10:58:31 CET 2017 From: Masashi Honma <masashi.honma(a)gmail.com> Date: Thu, 8 Dec 2016 10:15:50 +0900 Subject: mac80211: Remove invalid flag operations in mesh TSF synchronization From: Masashi Honma <masashi.honma(a)gmail.com> [ Upstream commit 76f43b4c0a9337af22827d78de4f2b8fd5328489 ] mesh_sync_offset_adjust_tbtt() implements Extensible synchronization framework ([1] 13.13.2 Extensible synchronization framework). It shall not operate the flag "TBTT Adjusting subfield" ([1] 8.4.2.100.8 Mesh Capability), since it is used only for MBCA ([1] 13.13.4 Mesh beacon collision avoidance, see 13.13.4.4.3 TBTT scanning and adjustment procedures for detail). So this patch remove the flag operations. [1] IEEE Std 802.11 2012 Signed-off-by: Masashi Honma <masashi.honma(a)gmail.com> [remove adjusting_tbtt entirely, since it's now unused] Signed-off-by: Johannes Berg <johannes.berg(a)intel.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/mac80211/ieee80211_i.h | 1 - net/mac80211/mesh.c | 3 --- net/mac80211/mesh_sync.c | 11 ----------- 3 files changed, 15 deletions(-) --- a/net/mac80211/ieee80211_i.h +++ b/net/mac80211/ieee80211_i.h @@ -640,7 +640,6 @@ struct ieee80211_if_mesh { const struct ieee80211_mesh_sync_ops *sync_ops; s64 sync_offset_clockdrift_max; spinlock_t sync_offset_lock; - bool adjusting_tbtt; /* mesh power save */ enum nl80211_mesh_power_mode nonpeer_pm; int ps_peers_light_sleep; --- a/net/mac80211/mesh.c +++ b/net/mac80211/mesh.c @@ -289,8 +289,6 @@ int mesh_add_meshconf_ie(struct ieee8021 /* Mesh PS mode. See IEEE802.11-2012 8.4.2.100.8 */ *pos |= ifmsh->ps_peers_deep_sleep ? IEEE80211_MESHCONF_CAPAB_POWER_SAVE_LEVEL : 0x00; - *pos++ |= ifmsh->adjusting_tbtt ? - IEEE80211_MESHCONF_CAPAB_TBTT_ADJUSTING : 0x00; *pos++ = 0x00; return 0; @@ -790,7 +788,6 @@ int ieee80211_start_mesh(struct ieee8021 ifmsh->mesh_cc_id = 0; /* Disabled */ /* register sync ops from extensible synchronization framework */ ifmsh->sync_ops = ieee80211_mesh_sync_ops_get(ifmsh->mesh_sp_id); - ifmsh->adjusting_tbtt = false; ifmsh->sync_offset_clockdrift_max = 0; set_bit(MESH_WORK_HOUSEKEEPING, &ifmsh->wrkq_flags); ieee80211_mesh_root_setup(ifmsh); --- a/net/mac80211/mesh_sync.c +++ b/net/mac80211/mesh_sync.c @@ -119,7 +119,6 @@ static void mesh_sync_offset_rx_bcn_pres */ if (elems->mesh_config && mesh_peer_tbtt_adjusting(elems)) { - clear_sta_flag(sta, WLAN_STA_TOFFSET_KNOWN); msync_dbg(sdata, "STA %pM : is adjusting TBTT\n", sta->sta.addr); goto no_sync; @@ -168,11 +167,9 @@ static void mesh_sync_offset_adjust_tbtt struct beacon_data *beacon) { struct ieee80211_if_mesh *ifmsh = &sdata->u.mesh; - u8 cap; WARN_ON(ifmsh->mesh_sp_id != IEEE80211_SYNC_METHOD_NEIGHBOR_OFFSET); WARN_ON(!rcu_read_lock_held()); - cap = beacon->meshconf->meshconf_cap; spin_lock_bh(&ifmsh->sync_offset_lock); @@ -186,21 +183,13 @@ static void mesh_sync_offset_adjust_tbtt "TBTT : kicking off TBTT adjustment with clockdrift_max=%lld\n", ifmsh->sync_offset_clockdrift_max); set_bit(MESH_WORK_DRIFT_ADJUST, &ifmsh->wrkq_flags); - - ifmsh->adjusting_tbtt = true; } else { msync_dbg(sdata, "TBTT : max clockdrift=%lld; too small to adjust\n", (long long)ifmsh->sync_offset_clockdrift_max); ifmsh->sync_offset_clockdrift_max = 0; - - ifmsh->adjusting_tbtt = false; } spin_unlock_bh(&ifmsh->sync_offset_lock); - - beacon->meshconf->meshconf_cap = ifmsh->adjusting_tbtt ? - IEEE80211_MESHCONF_CAPAB_TBTT_ADJUSTING | cap : - ~IEEE80211_MESHCONF_CAPAB_TBTT_ADJUSTING & cap; } static const struct sync_method sync_methods[] = { Patches currently in stable-queue which might be from masashi.honma(a)gmail.com are queue-3.18/mac80211-suppress-new_peer_candidate-event-if-no-room.patch queue-3.18/mac80211-remove-invalid-flag-operations-in-mesh-tsf-synchronization.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "drm/armada: Fix compile fail" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled drm/armada: Fix compile fail to the 3.18-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: drm-armada-fix-compile-fail.patch and it can be found in the queue-3.18 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 Tue Nov 28 10:58:31 CET 2017 From: Daniel Vetter <daniel.vetter(a)ffwll.ch> Date: Fri, 30 Dec 2016 17:38:52 +0100 Subject: drm/armada: Fix compile fail From: Daniel Vetter <daniel.vetter(a)ffwll.ch> [ Upstream commit 7357f89954b6d005df6ab8929759e78d7d9a80f9 ] I reported the include issue for tracepoints a while ago, but nothing seems to have happened. Now it bit us, since the drm_mm_print conversion was broken for armada. Fix it, so I can re-enable armada in the drm-misc build configs. v2: Rebase just the compile fix on top of Chris' build fix. Cc: Russell King <rmk+kernel(a)armlinux.org.uk> Cc: Chris Wilson <chris(a)chris-wilson.co.uk> Acked: Chris Wilson <chris(a)chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter(a)intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1483115932-19584-1-git-send-em… Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/gpu/drm/armada/Makefile | 2 ++ 1 file changed, 2 insertions(+) --- a/drivers/gpu/drm/armada/Makefile +++ b/drivers/gpu/drm/armada/Makefile @@ -5,3 +5,5 @@ armada-y += armada_510.o armada-$(CONFIG_DEBUG_FS) += armada_debugfs.o obj-$(CONFIG_DRM_ARMADA) := armada.o + +CFLAGS_armada_trace.o := -I$(src) Patches currently in stable-queue which might be from daniel.vetter(a)ffwll.ch are queue-3.18/drm-armada-fix-compile-fail.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "btrfs: return the actual error value from from btrfs_uuid_tree_iterate" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled btrfs: return the actual error value from from btrfs_uuid_tree_iterate to the 3.18-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: btrfs-return-the-actual-error-value-from-from-btrfs_uuid_tree_iterate.patch and it can be found in the queue-3.18 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 Tue Nov 28 10:58:31 CET 2017 From: Pan Bian <bianpan2016(a)163.com> Date: Sun, 4 Dec 2016 12:51:53 +0800 Subject: btrfs: return the actual error value from from btrfs_uuid_tree_iterate From: Pan Bian <bianpan2016(a)163.com> [ Upstream commit 73ba39ab9307340dc98ec3622891314bbc09cc2e ] In function btrfs_uuid_tree_iterate(), errno is assigned to variable ret on errors. However, it directly returns 0. It may be better to return ret. This patch also removes the warning, because the caller already prints a warning. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=188731 Signed-off-by: Pan Bian <bianpan2016(a)163.com> Reviewed-by: Omar Sandoval <osandov(a)fb.com> [ edited subject ] Signed-off-by: David Sterba <dsterba(a)suse.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/btrfs/uuid-tree.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) --- a/fs/btrfs/uuid-tree.c +++ b/fs/btrfs/uuid-tree.c @@ -348,7 +348,5 @@ skip: out: btrfs_free_path(path); - if (ret) - btrfs_warn(fs_info, "btrfs_uuid_tree_iterate failed %d", ret); - return 0; + return ret; } Patches currently in stable-queue which might be from bianpan2016(a)163.com are queue-3.18/net-3com-typhoon-typhoon_init_one-fix-incorrect-return-values.patch queue-3.18/btrfs-return-the-actual-error-value-from-from-btrfs_uuid_tree_iterate.patch queue-3.18/staging-iio-cdc-fix-improper-return-value.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "ASoC: wm_adsp: Don't overrun firmware file buffer when reading region data" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ASoC: wm_adsp: Don't overrun firmware file buffer when reading region data to the 3.18-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: asoc-wm_adsp-don-t-overrun-firmware-file-buffer-when-reading-region-data.patch and it can be found in the queue-3.18 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 Tue Nov 28 10:58:31 CET 2017 From: Richard Fitzgerald <rf(a)opensource.wolfsonmicro.com> Date: Tue, 20 Dec 2016 10:29:12 +0000 Subject: ASoC: wm_adsp: Don't overrun firmware file buffer when reading region data From: Richard Fitzgerald <rf(a)opensource.wolfsonmicro.com> [ Upstream commit 1cab2a84f470e15ecc8e5143bfe9398c6e888032 ] Protect against corrupt firmware files by ensuring that the length we get for the data in a region actually lies within the available firmware file data buffer. Signed-off-by: Richard Fitzgerald <rf(a)opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- sound/soc/codecs/wm_adsp.c | 25 ++++++++++++++++++++++++- 1 file changed, 24 insertions(+), 1 deletion(-) --- a/sound/soc/codecs/wm_adsp.c +++ b/sound/soc/codecs/wm_adsp.c @@ -532,7 +532,7 @@ static int wm_adsp_load(struct wm_adsp * const struct wmfw_region *region; const struct wm_adsp_region *mem; const char *region_name; - char *file, *text; + char *file, *text = NULL; struct wm_adsp_buf *buf; unsigned int reg; int regions = 0; @@ -677,10 +677,21 @@ static int wm_adsp_load(struct wm_adsp * regions, le32_to_cpu(region->len), offset, region_name); + if ((pos + le32_to_cpu(region->len) + sizeof(*region)) > + firmware->size) { + adsp_err(dsp, + "%s.%d: %s region len %d bytes exceeds file length %zu\n", + file, regions, region_name, + le32_to_cpu(region->len), firmware->size); + ret = -EINVAL; + goto out_fw; + } + if (text) { memcpy(text, region->data, le32_to_cpu(region->len)); adsp_info(dsp, "%s: %s\n", file, text); kfree(text); + text = NULL; } if (reg) { @@ -737,6 +748,7 @@ out_fw: regmap_async_complete(regmap); wm_adsp_buf_free(&buf_list); release_firmware(firmware); + kfree(text); out: kfree(file); @@ -1316,6 +1328,17 @@ static int wm_adsp_load_coeff(struct wm_ } if (reg) { + if ((pos + le32_to_cpu(blk->len) + sizeof(*blk)) > + firmware->size) { + adsp_err(dsp, + "%s.%d: %s region len %d bytes exceeds file length %zu\n", + file, blocks, region_name, + le32_to_cpu(blk->len), + firmware->size); + ret = -EINVAL; + goto out_fw; + } + buf = wm_adsp_buf_alloc(blk->data, le32_to_cpu(blk->len), &buf_list); Patches currently in stable-queue which might be from rf(a)opensource.wolfsonmicro.com are queue-3.18/asoc-wm_adsp-don-t-overrun-firmware-file-buffer-when-reading-region-data.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "ALSA: hda - Apply ALC269_FIXUP_NO_SHUTUP on HDA_FIXUP_ACT_PROBE" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ALSA: hda - Apply ALC269_FIXUP_NO_SHUTUP on HDA_FIXUP_ACT_PROBE to the 3.18-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: alsa-hda-apply-alc269_fixup_no_shutup-on-hda_fixup_act_probe.patch and it can be found in the queue-3.18 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 Tue Nov 28 10:58:31 CET 2017 From: Gabriele Mazzotta <gabriele.mzt(a)gmail.com> Date: Sat, 24 Dec 2016 19:50:00 +0100 Subject: ALSA: hda - Apply ALC269_FIXUP_NO_SHUTUP on HDA_FIXUP_ACT_PROBE From: Gabriele Mazzotta <gabriele.mzt(a)gmail.com> [ Upstream commit 972aa2c708703c21f14eb958b37e82aae2530e44 ] Setting shutup when the action is HDA_FIXUP_ACT_PRE_PROBE might not have the desired effect since it could be overridden by another more generic shutup function. Prevent this by setting the more specific shutup function on HDA_FIXUP_ACT_PROBE. Signed-off-by: Gabriele Mazzotta <gabriele.mzt(a)gmail.com> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- sound/pci/hda/patch_realtek.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -4289,7 +4289,7 @@ static void alc_no_shutup(struct hda_cod static void alc_fixup_no_shutup(struct hda_codec *codec, const struct hda_fixup *fix, int action) { - if (action == HDA_FIXUP_ACT_PRE_PROBE) { + if (action == HDA_FIXUP_ACT_PROBE) { struct alc_spec *spec = codec->spec; spec->shutup = alc_no_shutup; } Patches currently in stable-queue which might be from gabriele.mzt(a)gmail.com are queue-3.18/alsa-hda-apply-alc269_fixup_no_shutup-on-hda_fixup_act_probe.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "xen: xenbus driver must not accept invalid transaction ids" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled xen: xenbus driver must not accept invalid transaction ids to the 4.4-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: xen-xenbus-driver-must-not-accept-invalid-transaction-ids.patch and it can be found in the queue-4.4 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 Tue Nov 28 10:56:34 CET 2017 From: Juergen Gross <jgross(a)suse.com> Date: Thu, 22 Dec 2016 08:19:46 +0100 Subject: xen: xenbus driver must not accept invalid transaction ids From: Juergen Gross <jgross(a)suse.com> [ Upstream commit 639b08810d6ad74ded2c5f6e233c4fcb9d147168 ] When accessing Xenstore in a transaction the user is specifying a transaction id which he normally obtained from Xenstore when starting the transaction. Xenstore is validating a transaction id against all known transaction ids of the connection the request came in. As all requests of a domain not being the one where Xenstore lives share one connection, validation of transaction ids of different users of Xenstore in that domain should be done by the kernel of that domain being the multiplexer between the Xenstore users in that domain and Xenstore. In order to prohibit one Xenstore user "hijacking" a transaction from another user the xenbus driver has to verify a given transaction id against all known transaction ids of the user before forwarding it to Xenstore. Signed-off-by: Juergen Gross <jgross(a)suse.com> Reviewed-by: Boris Ostrovsky <boris.ostrovsky(a)oracle.com> Signed-off-by: Juergen Gross <jgross(a)suse.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/xen/xenbus/xenbus_dev_frontend.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/xen/xenbus/xenbus_dev_frontend.c +++ b/drivers/xen/xenbus/xenbus_dev_frontend.c @@ -316,7 +316,7 @@ static int xenbus_write_transaction(unsi rc = -ENOMEM; goto out; } - } else if (msg_type == XS_TRANSACTION_END) { + } else if (u->u.msg.tx_id != 0) { list_for_each_entry(trans, &u->transactions, list) if (trans->handle.id == u->u.msg.tx_id) break; Patches currently in stable-queue which might be from jgross(a)suse.com are queue-4.4/xen-xenbus-driver-must-not-accept-invalid-transaction-ids.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "staging: iio: cdc: fix improper return value" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled staging: iio: cdc: fix improper return value to the 4.4-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: staging-iio-cdc-fix-improper-return-value.patch and it can be found in the queue-4.4 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 Tue Nov 28 10:56:34 CET 2017 From: Pan Bian <bianpan2016(a)163.com> Date: Sat, 3 Dec 2016 21:44:30 +0800 Subject: staging: iio: cdc: fix improper return value From: Pan Bian <bianpan2016(a)163.com> [ Upstream commit 91ca1a8c584f55857b1f6ab20a1d3a1ce7a559bb ] At the end of function ad7150_write_event_config(), directly returns 0. As a result, the errors will be ignored by the callers. It may be better to return variable "ret". Signed-off-by: Pan Bian <bianpan2016(a)163.com> Signed-off-by: Jonathan Cameron <jic23(a)kernel.org> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/staging/iio/cdc/ad7150.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/staging/iio/cdc/ad7150.c +++ b/drivers/staging/iio/cdc/ad7150.c @@ -272,7 +272,7 @@ static int ad7150_write_event_config(str error_ret: mutex_unlock(&chip->state_lock); - return 0; + return ret; } static int ad7150_read_event_value(struct iio_dev *indio_dev, Patches currently in stable-queue which might be from bianpan2016(a)163.com are queue-4.4/iio-light-fix-improper-return-value.patch queue-4.4/net-3com-typhoon-typhoon_init_one-fix-incorrect-return-values.patch queue-4.4/btrfs-return-the-actual-error-value-from-from-btrfs_uuid_tree_iterate.patch queue-4.4/staging-iio-cdc-fix-improper-return-value.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "spi: SPI_FSL_DSPI should depend on HAS_DMA" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled spi: SPI_FSL_DSPI should depend on HAS_DMA to the 4.4-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: spi-spi_fsl_dspi-should-depend-on-has_dma.patch and it can be found in the queue-4.4 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 Tue Nov 28 10:56:34 CET 2017 From: Geert Uytterhoeven <geert(a)linux-m68k.org> Date: Wed, 14 Dec 2016 13:28:05 +0100 Subject: spi: SPI_FSL_DSPI should depend on HAS_DMA From: Geert Uytterhoeven <geert(a)linux-m68k.org> [ Upstream commit dadab2d4e3cf708ceba22ecddd94aedfecb39199 ] If NO_DMA=y: ERROR: "bad_dma_ops" [drivers/spi/spi-fsl-dspi.ko] undefined! Add a dependency on HAS_DMA to fix this. Signed-off-by: Geert Uytterhoeven <geert(a)linux-m68k.org> Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/spi/Kconfig | 1 + 1 file changed, 1 insertion(+) --- a/drivers/spi/Kconfig +++ b/drivers/spi/Kconfig @@ -315,6 +315,7 @@ config SPI_FSL_SPI config SPI_FSL_DSPI tristate "Freescale DSPI controller" select REGMAP_MMIO + depends on HAS_DMA depends on SOC_VF610 || SOC_LS1021A || ARCH_LAYERSCAPE || COMPILE_TEST help This enables support for the Freescale DSPI controller in master Patches currently in stable-queue which might be from geert(a)linux-m68k.org are queue-4.4/spi-spi_fsl_dspi-should-depend-on-has_dma.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "s390/kbuild: enable modversions for symbols exported from asm" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled s390/kbuild: enable modversions for symbols exported from asm to the 4.4-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: s390-kbuild-enable-modversions-for-symbols-exported-from-asm.patch and it can be found in the queue-4.4 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 Tue Nov 28 10:56:34 CET 2017 From: Heiko Carstens <heiko.carstens(a)de.ibm.com> Date: Tue, 20 Dec 2016 12:58:10 +0100 Subject: s390/kbuild: enable modversions for symbols exported from asm From: Heiko Carstens <heiko.carstens(a)de.ibm.com> [ Upstream commit cabab3f9f5ca077535080b3252e6168935b914af ] s390 version of commit 334bb7738764 ("x86/kbuild: enable modversions for symbols exported from asm") so we get also rid of all these warnings: WARNING: EXPORT symbol "_mcount" [vmlinux] version generation failed, symbol will not be versioned. WARNING: EXPORT symbol "memcpy" [vmlinux] version generation failed, symbol will not be versioned. WARNING: EXPORT symbol "memmove" [vmlinux] version generation failed, symbol will not be versioned. WARNING: EXPORT symbol "memset" [vmlinux] version generation failed, symbol will not be versioned. WARNING: EXPORT symbol "save_fpu_regs" [vmlinux] version generation failed, symbol will not be versioned. WARNING: EXPORT symbol "sie64a" [vmlinux] version generation failed, symbol will not be versioned. WARNING: EXPORT symbol "sie_exit" [vmlinux] version generation failed, symbol will not be versioned. Signed-off-by: Heiko Carstens <heiko.carstens(a)de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky(a)de.ibm.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/s390/include/asm/asm-prototypes.h | 8 ++++++++ 1 file changed, 8 insertions(+) create mode 100644 arch/s390/include/asm/asm-prototypes.h --- /dev/null +++ b/arch/s390/include/asm/asm-prototypes.h @@ -0,0 +1,8 @@ +#ifndef _ASM_S390_PROTOTYPES_H + +#include <linux/kvm_host.h> +#include <linux/ftrace.h> +#include <asm/fpu/api.h> +#include <asm-generic/asm-prototypes.h> + +#endif /* _ASM_S390_PROTOTYPES_H */ Patches currently in stable-queue which might be from heiko.carstens(a)de.ibm.com are queue-4.4/s390-disassembler-add-missing-end-marker-for-e7-table.patch queue-4.4/s390-kbuild-enable-modversions-for-symbols-exported-from-asm.patch queue-4.4/s390-fix-transactional-execution-control-register-handling.patch queue-4.4/s390-runtime-instrumention-fix-possible-memory-corruption.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] [GIT PULL] commits for Linux 4.4

by alexander.levin＠verizon.com

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi Greg, Pleae pull commits for Linux 4.4 . I've sent a review request for all commits over a week ago and all comments were addressed. Thanks, Sasha ===== The following changes since commit 29ffb9c1fb4acbda207985ad1558191ffb776bee: Linux 4.4.102 (2017-11-24 11:26:29 +0100) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/sashal/linux-stable.git for-greg-4.4-2 for you to fetch changes up to f5e41e5d854fec2295f485165228715f558959c7: xen: xenbus driver must not accept invalid transaction ids (2017-11-24 10:51:05 -0500) - ---------------------------------------------------------------- Bartosz Markowski (1): ath10k: set CTS protection VDEV param only if VDEV is up Bjorn Helgaas (1): PCI: Apply _HPX settings only to relevant devices Chris Wilson (1): drm: Apply range restriction after color adjustment when allocation Christian Lamparter (1): ath10k: fix potential memory leak in ath10k_wmi_tlv_op_pull_fw_stats() Colin Ian King (1): ASoC: rsnd: don't double free kctrl Daniel Vetter (1): drm/armada: Fix compile fail David Ahern (1): net: Allow IP_MULTICAST_IF to set index to L3 slave Florian Westphal (1): netfilter: nf_tables: fix oob access Gabriele Mazzotta (1): ALSA: hda - Apply ALC269_FIXUP_NO_SHUTUP on HDA_FIXUP_ACT_PROBE Geert Uytterhoeven (1): spi: SPI_FSL_DSPI should depend on HAS_DMA Heiko Carstens (1): s390/kbuild: enable modversions for symbols exported from asm Juergen Gross (1): xen: xenbus driver must not accept invalid transaction ids Masashi Honma (2): mac80211: Remove invalid flag operations in mesh TSF synchronization mac80211: Suppress NEW_PEER_CANDIDATE event if no room Pablo Neira Ayuso (1): netfilter: nft_queue: use raw_smp_processor_id() Pan Bian (3): iio: light: fix improper return value staging: iio: cdc: fix improper return value btrfs: return the actual error value from from btrfs_uuid_tree_iterate Richard Fitzgerald (1): ASoC: wm_adsp: Don't overrun firmware file buffer when reading region data Ryan Hsu (2): ath10k: fix incorrect txpower set by P2P_DEVICE interface ath10k: ignore configuring the incorrect board_id Santosh Shilimkar (1): RDS: RDMA: return appropriate error on rdma map failures Shawn Guo (1): dmaengine: zx: set DMA_CYCLIC cap_mask bit Thomas Preisner (2): net: 3com: typhoon: typhoon_init_one: make return values more specific net: 3com: typhoon: typhoon_init_one: fix incorrect return values arch/s390/include/asm/asm-prototypes.h | 8 +++++ drivers/dma/zx296702_dma.c | 1 + drivers/gpu/drm/armada/Makefile | 2 ++ drivers/gpu/drm/drm_mm.c | 16 ++++----- drivers/iio/light/cm3232.c | 2 +- drivers/net/ethernet/3com/typhoon.c | 25 +++++++------ drivers/net/wireless/ath/ath10k/core.c | 5 ++- drivers/net/wireless/ath/ath10k/mac.c | 58 +++++++++++++++++++++++++------ drivers/net/wireless/ath/ath10k/wmi-tlv.c | 12 +++++-- drivers/pci/probe.c | 15 ++++++-- drivers/spi/Kconfig | 1 + drivers/staging/iio/cdc/ad7150.c | 2 +- drivers/xen/xenbus/xenbus_dev_frontend.c | 2 +- fs/btrfs/uuid-tree.c | 4 +-- net/ipv4/ip_sockglue.c | 7 +++- net/ipv6/ipv6_sockglue.c | 16 ++++++--- net/mac80211/ieee80211_i.h | 1 - net/mac80211/mesh.c | 3 -- net/mac80211/mesh_plink.c | 14 ++++---- net/mac80211/mesh_sync.c | 11 ------ net/netfilter/nf_tables_api.c | 2 +- net/netfilter/nft_queue.c | 2 +- net/rds/send.c | 11 +++++- sound/pci/hda/patch_realtek.c | 2 +- sound/soc/codecs/wm_adsp.c | 25 ++++++++++++- sound/soc/sh/rcar/core.c | 4 +-- 26 files changed, 173 insertions(+), 78 deletions(-) create mode 100644 arch/s390/include/asm/asm-prototypes.h -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJaGFNwAAoJEN6mb/eXdyzcaMIP/RqzUtHblgCVIoSoj6E1+9Sf ERGdchq5yxMSGybQg3JIGXPqftSzw9iggGd0eUBxjeQrnyvNJMPadr1UkgUoKR+q ecss60cwSZlgaBxLEBB3/2Z+oPUK985qoY1G9/Qt6NGusYHmSuTDvyGNdV79zK1Z zZN5lrqiZtZ/171sDKPTgp97PO7Bkhaui2KEUrs8FaR1Au8x0qFnRuM78JX6vogp CA5o7nD8IvGw61rVDPNm+jN8KoitVvWERjMxw6RyxgSJln2Kph0FiGw+bZZ/NQSA jggBw1ehsScu/YBAZFECOWZ+6Zbw0jJCm+rny+pG13ffDYhsQ4P8wLXB/sbr+BT2 hTjN8akxz88S/AoLy4rzvR5izoqr1kJbyxoSnrrIDk0l+n2L99pqQiYpPNeB30ys 0r3orcCDyV5NQFvIrZyVdzM4lKST3cxSeB82X/rInLX+dS5kAvBnKUdhun+DFyjA iOwQuZr8GYgR9IZIxRNdNhU69ZffsVYlE2knR8+rlR2hEKMzmCV6YwETDm7JEML+ p66TYnP7Op9TVHMJA2wjTomaH20IYzyoXhmkso3Q3qT7AcOQRFmggv8ESIWiXmLF 24dmLJNE99gMzf9T37qfXLU8FhaYVDN+8udcPvGPRtXhOpnyhpAhEH6QhqgczATm FUpQYKd7cEXa5xDcP52r =aqWO -----END PGP SIGNATURE-----

7 years, 5 months

2
1
0 0

[Linux-stable-mirror] Patch "RDS: RDMA: return appropriate error on rdma map failures" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled RDS: RDMA: return appropriate error on rdma map failures to the 4.4-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: rds-rdma-return-appropriate-error-on-rdma-map-failures.patch and it can be found in the queue-4.4 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 Tue Nov 28 10:56:34 CET 2017 From: Santosh Shilimkar <santosh.shilimkar(a)oracle.com> Date: Mon, 4 Jul 2016 17:04:37 -0700 Subject: RDS: RDMA: return appropriate error on rdma map failures From: Santosh Shilimkar <santosh.shilimkar(a)oracle.com> [ Upstream commit 584a8279a44a800dea5a5c1e9d53a002e03016b4 ] The first message to a remote node should prompt a new connection even if it is RDMA operation. For RDMA operation the MR mapping can fail because connections is not yet up. Since the connection establishment is asynchronous, we make sure the map failure because of unavailable connection reach to the user by appropriate error code. Before returning to the user, lets trigger the connection so that its ready for the next retry. Signed-off-by: Santosh Shilimkar <santosh.shilimkar(a)oracle.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/rds/send.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) --- a/net/rds/send.c +++ b/net/rds/send.c @@ -959,6 +959,11 @@ static int rds_cmsg_send(struct rds_sock ret = rds_cmsg_rdma_map(rs, rm, cmsg); if (!ret) *allocated_mr = 1; + else if (ret == -ENODEV) + /* Accommodate the get_mr() case which can fail + * if connection isn't established yet. + */ + ret = -EAGAIN; break; case RDS_CMSG_ATOMIC_CSWP: case RDS_CMSG_ATOMIC_FADD: @@ -1072,8 +1077,12 @@ int rds_sendmsg(struct socket *sock, str /* Parse any control messages the user may have included. */ ret = rds_cmsg_send(rs, rm, msg, &allocated_mr); - if (ret) + if (ret) { + /* Trigger connection so that its ready for the next retry */ + if (ret == -EAGAIN) + rds_conn_connect_if_down(conn); goto out; + } if (rm->rdma.op_active && !conn->c_trans->xmit_rdma) { printk_ratelimited(KERN_NOTICE "rdma_op %p conn xmit_rdma %p\n", Patches currently in stable-queue which might be from santosh.shilimkar(a)oracle.com are queue-4.4/rds-rdma-return-appropriate-error-on-rdma-map-failures.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "PCI: Apply _HPX settings only to relevant devices" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled PCI: Apply _HPX settings only to relevant devices to the 4.4-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: pci-apply-_hpx-settings-only-to-relevant-devices.patch and it can be found in the queue-4.4 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 Tue Nov 28 10:56:34 CET 2017 From: Bjorn Helgaas <bhelgaas(a)google.com> Date: Mon, 2 Jan 2017 14:04:24 -0600 Subject: PCI: Apply _HPX settings only to relevant devices From: Bjorn Helgaas <bhelgaas(a)google.com> [ Upstream commit 977509f7c5c6fb992ffcdf4291051af343b91645 ] Previously we didn't check the type of device before trying to apply Type 1 (PCI-X) or Type 2 (PCIe) Setting Records from _HPX. We don't support PCI-X Setting Records, so this was harmless, but the warning was useless. We do support PCIe Setting Records, and we didn't check whether a device was PCIe before applying settings. I don't think anything bad happened on non-PCIe devices because pcie_capability_clear_and_set_word(), pcie_cap_has_lnkctl(), etc., would fail before doing any harm. But it's ugly to depend on those internals. Check the device type before attempting to apply Type 1 and Type 2 Setting Records (Type 0 records are applicable to PCI, PCI-X, and PCIe devices). A side benefit is that this prevents useless "not supported" warnings when a BIOS supplies a Type 1 (PCI-X) Setting Record and we try to apply it to every single device: pci 0000:00:00.0: PCI-X settings not supported After this patch, we'll get the warning only when a BIOS supplies a Type 1 record and we have a PCI-X device to which it should be applied. Link: https://bugzilla.kernel.org/show_bug.cgi?id=187731 Signed-off-by: Bjorn Helgaas <bhelgaas(a)google.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/pci/probe.c | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-) --- a/drivers/pci/probe.c +++ b/drivers/pci/probe.c @@ -1414,8 +1414,16 @@ static void program_hpp_type0(struct pci static void program_hpp_type1(struct pci_dev *dev, struct hpp_type1 *hpp) { - if (hpp) - dev_warn(&dev->dev, "PCI-X settings not supported\n"); + int pos; + + if (!hpp) + return; + + pos = pci_find_capability(dev, PCI_CAP_ID_PCIX); + if (!pos) + return; + + dev_warn(&dev->dev, "PCI-X settings not supported\n"); } static bool pcie_root_rcb_set(struct pci_dev *dev) @@ -1441,6 +1449,9 @@ static void program_hpp_type2(struct pci if (!hpp) return; + if (!pci_is_pcie(dev)) + return; + if (hpp->revision > 1) { dev_warn(&dev->dev, "PCIe settings rev %d not supported\n", hpp->revision); Patches currently in stable-queue which might be from bhelgaas(a)google.com are queue-4.4/pci-apply-_hpx-settings-only-to-relevant-devices.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "netfilter: nft_queue: use raw_smp_processor_id()" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled netfilter: nft_queue: use raw_smp_processor_id() to the 4.4-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: netfilter-nft_queue-use-raw_smp_processor_id.patch and it can be found in the queue-4.4 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 Tue Nov 28 10:56:34 CET 2017 From: Pablo Neira Ayuso <pablo(a)netfilter.org> Date: Sun, 11 Dec 2016 20:46:51 +0100 Subject: netfilter: nft_queue: use raw_smp_processor_id() From: Pablo Neira Ayuso <pablo(a)netfilter.org> [ Upstream commit c2e756ff9e699865d294cdc112acfc36419cf5cc ] Using smp_processor_id() causes splats with PREEMPT_RCU: [19379.552780] BUG: using smp_processor_id() in preemptible [00000000] code: ping/32389 [19379.552793] caller is debug_smp_processor_id+0x17/0x19 [...] [19379.552823] Call Trace: [19379.552832] [<ffffffff81274e9e>] dump_stack+0x67/0x90 [19379.552837] [<ffffffff8129a4d4>] check_preemption_disabled+0xe5/0xf5 [19379.552842] [<ffffffff8129a4fb>] debug_smp_processor_id+0x17/0x19 [19379.552849] [<ffffffffa07c42dd>] nft_queue_eval+0x35/0x20c [nft_queue] No need to disable preemption since we only fetch the numeric value, so let's use raw_smp_processor_id() instead. Signed-off-by: Pablo Neira Ayuso <pablo(a)netfilter.org> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/netfilter/nft_queue.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/net/netfilter/nft_queue.c +++ b/net/netfilter/nft_queue.c @@ -37,7 +37,7 @@ static void nft_queue_eval(const struct if (priv->queues_total > 1) { if (priv->flags & NFT_QUEUE_FLAG_CPU_FANOUT) { - int cpu = smp_processor_id(); + int cpu = raw_smp_processor_id(); queue = priv->queuenum + cpu % priv->queues_total; } else { Patches currently in stable-queue which might be from pablo(a)netfilter.org are queue-4.4/netfilter-nf_tables-fix-oob-access.patch queue-4.4/netfilter-nft_queue-use-raw_smp_processor_id.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "netfilter: nf_tables: fix oob access" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled netfilter: nf_tables: fix oob access to the 4.4-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: netfilter-nf_tables-fix-oob-access.patch and it can be found in the queue-4.4 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 Tue Nov 28 10:56:34 CET 2017 From: Florian Westphal <fw(a)strlen.de> Date: Tue, 13 Dec 2016 13:59:33 +0100 Subject: netfilter: nf_tables: fix oob access From: Florian Westphal <fw(a)strlen.de> [ Upstream commit 3e38df136e453aa69eb4472108ebce2fb00b1ba6 ] BUG: KASAN: slab-out-of-bounds in nf_tables_rule_destroy+0xf1/0x130 at addr ffff88006a4c35c8 Read of size 8 by task nft/1607 When we've destroyed last valid expr, nft_expr_next() returns an invalid expr. We must not dereference it unless it passes != nft_expr_last() check. Signed-off-by: Florian Westphal <fw(a)strlen.de> Signed-off-by: Pablo Neira Ayuso <pablo(a)netfilter.org> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/netfilter/nf_tables_api.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/net/netfilter/nf_tables_api.c +++ b/net/netfilter/nf_tables_api.c @@ -1996,7 +1996,7 @@ static void nf_tables_rule_destroy(const * is called on error from nf_tables_newrule(). */ expr = nft_expr_first(rule); - while (expr->ops && expr != nft_expr_last(rule)) { + while (expr != nft_expr_last(rule) && expr->ops) { nf_tables_expr_destroy(ctx, expr); expr = nft_expr_next(expr); } Patches currently in stable-queue which might be from fw(a)strlen.de are queue-4.4/netfilter-nf_tables-fix-oob-access.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "net: Allow IP_MULTICAST_IF to set index to L3 slave" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled net: Allow IP_MULTICAST_IF to set index to L3 slave to the 4.4-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: net-allow-ip_multicast_if-to-set-index-to-l3-slave.patch and it can be found in the queue-4.4 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 Tue Nov 28 10:56:34 CET 2017 From: David Ahern <dsa(a)cumulusnetworks.com> Date: Thu, 29 Dec 2016 15:39:37 -0800 Subject: net: Allow IP_MULTICAST_IF to set index to L3 slave From: David Ahern <dsa(a)cumulusnetworks.com> [ Upstream commit 7bb387c5ab12aeac3d5eea28686489ff46b53ca9 ] IP_MULTICAST_IF fails if sk_bound_dev_if is already set and the new index does not match it. e.g., ntpd[15381]: setsockopt IP_MULTICAST_IF 192.168.1.23 fails: Invalid argument Relax the check in setsockopt to allow setting mc_index to an L3 slave if sk_bound_dev_if points to an L3 master. Make a similar change for IPv6. In this case change the device lookup to take the rcu_read_lock avoiding a refcnt. The rcu lock is also needed for the lookup of a potential L3 master device. This really only silences a setsockopt failure since uses of mc_index are secondary to sk_bound_dev_if if it is set. In both cases, if either index is an L3 slave or master, lookups are directed to the same FIB table so relaxing the check at setsockopt time causes no harm. Patch is based on a suggested change by Darwin for a problem noted in their code base. Suggested-by: Darwin Dingel <darwin.dingel(a)alliedtelesis.co.nz> Signed-off-by: David Ahern <dsa(a)cumulusnetworks.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> --- net/ipv4/ip_sockglue.c | 7 ++++++- net/ipv6/ipv6_sockglue.c | 16 ++++++++++++---- 2 files changed, 18 insertions(+), 5 deletions(-) --- a/net/ipv4/ip_sockglue.c +++ b/net/ipv4/ip_sockglue.c @@ -808,6 +808,7 @@ static int do_ip_setsockopt(struct sock { struct ip_mreqn mreq; struct net_device *dev = NULL; + int midx; if (sk->sk_type == SOCK_STREAM) goto e_inval; @@ -852,11 +853,15 @@ static int do_ip_setsockopt(struct sock err = -EADDRNOTAVAIL; if (!dev) break; + + midx = l3mdev_master_ifindex(dev); + dev_put(dev); err = -EINVAL; if (sk->sk_bound_dev_if && - mreq.imr_ifindex != sk->sk_bound_dev_if) + mreq.imr_ifindex != sk->sk_bound_dev_if && + (!midx || midx != sk->sk_bound_dev_if)) break; inet->mc_index = mreq.imr_ifindex; --- a/net/ipv6/ipv6_sockglue.c +++ b/net/ipv6/ipv6_sockglue.c @@ -583,16 +583,24 @@ done: if (val) { struct net_device *dev; + int midx; - if (sk->sk_bound_dev_if && sk->sk_bound_dev_if != val) - goto e_inval; + rcu_read_lock(); - dev = dev_get_by_index(net, val); + dev = dev_get_by_index_rcu(net, val); if (!dev) { + rcu_read_unlock(); retv = -ENODEV; break; } - dev_put(dev); + midx = l3mdev_master_ifindex_rcu(dev); + + rcu_read_unlock(); + + if (sk->sk_bound_dev_if && + sk->sk_bound_dev_if != val && + (!midx || midx != sk->sk_bound_dev_if)) + goto e_inval; } np->mcast_oif = val; retv = 0; Patches currently in stable-queue which might be from dsa(a)cumulusnetworks.com are queue-4.4/net-allow-ip_multicast_if-to-set-index-to-l3-slave.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "net: 3com: typhoon: typhoon_init_one: make return values more specific" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled net: 3com: typhoon: typhoon_init_one: make return values more specific to the 4.4-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: net-3com-typhoon-typhoon_init_one-make-return-values-more-specific.patch and it can be found in the queue-4.4 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 Tue Nov 28 10:56:34 CET 2017 From: Thomas Preisner <thomas.preisner+linux(a)fau.de> Date: Fri, 30 Dec 2016 03:37:54 +0100 Subject: net: 3com: typhoon: typhoon_init_one: make return values more specific From: Thomas Preisner <thomas.preisner+linux(a)fau.de> [ Upstream commit 6b6bbb5922a4b1d4b58125a572da91010295fba3 ] In some cases the return value of a failing function is not being used and the function typhoon_init_one() returns another negative error code instead. Signed-off-by: Thomas Preisner <thomas.preisner+linux(a)fau.de> Signed-off-by: Milan Stephan <milan.stephan+linux(a)fau.de> 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/3com/typhoon.c | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) --- a/drivers/net/ethernet/3com/typhoon.c +++ b/drivers/net/ethernet/3com/typhoon.c @@ -2366,9 +2366,9 @@ typhoon_init_one(struct pci_dev *pdev, c * 4) Get the hardware address. * 5) Put the card to sleep. */ - if (typhoon_reset(ioaddr, WaitSleep) < 0) { + err = typhoon_reset(ioaddr, WaitSleep); + if (err < 0) { err_msg = "could not reset 3XP"; - err = -EIO; goto error_out_dma; } @@ -2382,16 +2382,16 @@ typhoon_init_one(struct pci_dev *pdev, c typhoon_init_interface(tp); typhoon_init_rings(tp); - if(typhoon_boot_3XP(tp, TYPHOON_STATUS_WAITING_FOR_HOST) < 0) { + err = typhoon_boot_3XP(tp, TYPHOON_STATUS_WAITING_FOR_HOST); + if (err < 0) { err_msg = "cannot boot 3XP sleep image"; - err = -EIO; goto error_out_reset; } INIT_COMMAND_WITH_RESPONSE(&xp_cmd, TYPHOON_CMD_READ_MAC_ADDRESS); - if(typhoon_issue_command(tp, 1, &xp_cmd, 1, xp_resp) < 0) { + err = typhoon_issue_command(tp, 1, &xp_cmd, 1, xp_resp); + if (err < 0) { err_msg = "cannot read MAC address"; - err = -EIO; goto error_out_reset; } @@ -2424,9 +2424,9 @@ typhoon_init_one(struct pci_dev *pdev, c if(xp_resp[0].numDesc != 0) tp->capabilities |= TYPHOON_WAKEUP_NEEDS_RESET; - if(typhoon_sleep(tp, PCI_D3hot, 0) < 0) { + err = typhoon_sleep(tp, PCI_D3hot, 0); + if (err < 0) { err_msg = "cannot put adapter to sleep"; - err = -EIO; goto error_out_reset; } Patches currently in stable-queue which might be from thomas.preisner+linux(a)fau.de are queue-4.4/net-3com-typhoon-typhoon_init_one-fix-incorrect-return-values.patch queue-4.4/net-3com-typhoon-typhoon_init_one-make-return-values-more-specific.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "net: 3com: typhoon: typhoon_init_one: fix incorrect return values" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled net: 3com: typhoon: typhoon_init_one: fix incorrect return values to the 4.4-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: net-3com-typhoon-typhoon_init_one-fix-incorrect-return-values.patch and it can be found in the queue-4.4 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 Tue Nov 28 10:56:34 CET 2017 From: Thomas Preisner <thomas.preisner+linux(a)fau.de> Date: Fri, 30 Dec 2016 03:37:53 +0100 Subject: net: 3com: typhoon: typhoon_init_one: fix incorrect return values From: Thomas Preisner <thomas.preisner+linux(a)fau.de> [ Upstream commit 107fded7bf616ad6f46823d98b8ed6405d7adf2d ] In a few cases the err-variable is not set to a negative error code if a function call in typhoon_init_one() fails and thus 0 is returned instead. It may be better to set err to the appropriate negative error code before returning. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=188841 Reported-by: Pan Bian <bianpan2016(a)163.com> Signed-off-by: Thomas Preisner <thomas.preisner+linux(a)fau.de> Signed-off-by: Milan Stephan <milan.stephan+linux(a)fau.de> 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/3com/typhoon.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) --- a/drivers/net/ethernet/3com/typhoon.c +++ b/drivers/net/ethernet/3com/typhoon.c @@ -2398,8 +2398,9 @@ typhoon_init_one(struct pci_dev *pdev, c *(__be16 *)&dev->dev_addr[0] = htons(le16_to_cpu(xp_resp[0].parm1)); *(__be32 *)&dev->dev_addr[2] = htonl(le32_to_cpu(xp_resp[0].parm2)); - if(!is_valid_ether_addr(dev->dev_addr)) { + if (!is_valid_ether_addr(dev->dev_addr)) { err_msg = "Could not obtain valid ethernet address, aborting"; + err = -EIO; goto error_out_reset; } @@ -2407,7 +2408,8 @@ typhoon_init_one(struct pci_dev *pdev, c * later when we print out the version reported. */ INIT_COMMAND_WITH_RESPONSE(&xp_cmd, TYPHOON_CMD_READ_VERSIONS); - if(typhoon_issue_command(tp, 1, &xp_cmd, 3, xp_resp) < 0) { + err = typhoon_issue_command(tp, 1, &xp_cmd, 3, xp_resp); + if (err < 0) { err_msg = "Could not get Sleep Image version"; goto error_out_reset; } @@ -2449,7 +2451,8 @@ typhoon_init_one(struct pci_dev *pdev, c dev->features = dev->hw_features | NETIF_F_HW_VLAN_CTAG_RX | NETIF_F_RXCSUM; - if(register_netdev(dev) < 0) { + err = register_netdev(dev); + if (err < 0) { err_msg = "unable to register netdev"; goto error_out_reset; } Patches currently in stable-queue which might be from thomas.preisner+linux(a)fau.de are queue-4.4/net-3com-typhoon-typhoon_init_one-fix-incorrect-return-values.patch queue-4.4/net-3com-typhoon-typhoon_init_one-make-return-values-more-specific.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "mac80211: Suppress NEW_PEER_CANDIDATE event if no room" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled mac80211: Suppress NEW_PEER_CANDIDATE event if no room to the 4.4-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: mac80211-suppress-new_peer_candidate-event-if-no-room.patch and it can be found in the queue-4.4 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 Tue Nov 28 10:56:34 CET 2017 From: Masashi Honma <masashi.honma(a)gmail.com> Date: Wed, 30 Nov 2016 09:06:04 +0900 Subject: mac80211: Suppress NEW_PEER_CANDIDATE event if no room From: Masashi Honma <masashi.honma(a)gmail.com> [ Upstream commit 11197d006bcfabf0173a7820a163fcaac420d10e ] Previously, kernel sends NEW_PEER_CANDIDATE event to user land even if the found peer does not have any room to accept other peer. This causes continuous connection trials. Signed-off-by: Masashi Honma <masashi.honma(a)gmail.com> Signed-off-by: Johannes Berg <johannes.berg(a)intel.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/mac80211/mesh_plink.c | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) --- a/net/mac80211/mesh_plink.c +++ b/net/mac80211/mesh_plink.c @@ -495,12 +495,14 @@ mesh_sta_info_alloc(struct ieee80211_sub /* Userspace handles station allocation */ if (sdata->u.mesh.user_mpm || - sdata->u.mesh.security & IEEE80211_MESH_SEC_AUTHED) - cfg80211_notify_new_peer_candidate(sdata->dev, addr, - elems->ie_start, - elems->total_len, - GFP_KERNEL); - else + sdata->u.mesh.security & IEEE80211_MESH_SEC_AUTHED) { + if (mesh_peer_accepts_plinks(elems) && + mesh_plink_availables(sdata)) + cfg80211_notify_new_peer_candidate(sdata->dev, addr, + elems->ie_start, + elems->total_len, + GFP_KERNEL); + } else sta = __mesh_sta_info_alloc(sdata, addr); return sta; Patches currently in stable-queue which might be from masashi.honma(a)gmail.com are queue-4.4/mac80211-suppress-new_peer_candidate-event-if-no-room.patch queue-4.4/mac80211-remove-invalid-flag-operations-in-mesh-tsf-synchronization.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "mac80211: Remove invalid flag operations in mesh TSF synchronization" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled mac80211: Remove invalid flag operations in mesh TSF synchronization to the 4.4-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: mac80211-remove-invalid-flag-operations-in-mesh-tsf-synchronization.patch and it can be found in the queue-4.4 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 Tue Nov 28 10:56:34 CET 2017 From: Masashi Honma <masashi.honma(a)gmail.com> Date: Thu, 8 Dec 2016 10:15:50 +0900 Subject: mac80211: Remove invalid flag operations in mesh TSF synchronization From: Masashi Honma <masashi.honma(a)gmail.com> [ Upstream commit 76f43b4c0a9337af22827d78de4f2b8fd5328489 ] mesh_sync_offset_adjust_tbtt() implements Extensible synchronization framework ([1] 13.13.2 Extensible synchronization framework). It shall not operate the flag "TBTT Adjusting subfield" ([1] 8.4.2.100.8 Mesh Capability), since it is used only for MBCA ([1] 13.13.4 Mesh beacon collision avoidance, see 13.13.4.4.3 TBTT scanning and adjustment procedures for detail). So this patch remove the flag operations. [1] IEEE Std 802.11 2012 Signed-off-by: Masashi Honma <masashi.honma(a)gmail.com> [remove adjusting_tbtt entirely, since it's now unused] Signed-off-by: Johannes Berg <johannes.berg(a)intel.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/mac80211/ieee80211_i.h | 1 - net/mac80211/mesh.c | 3 --- net/mac80211/mesh_sync.c | 11 ----------- 3 files changed, 15 deletions(-) --- a/net/mac80211/ieee80211_i.h +++ b/net/mac80211/ieee80211_i.h @@ -682,7 +682,6 @@ struct ieee80211_if_mesh { const struct ieee80211_mesh_sync_ops *sync_ops; s64 sync_offset_clockdrift_max; spinlock_t sync_offset_lock; - bool adjusting_tbtt; /* mesh power save */ enum nl80211_mesh_power_mode nonpeer_pm; int ps_peers_light_sleep; --- a/net/mac80211/mesh.c +++ b/net/mac80211/mesh.c @@ -295,8 +295,6 @@ int mesh_add_meshconf_ie(struct ieee8021 /* Mesh PS mode. See IEEE802.11-2012 8.4.2.100.8 */ *pos |= ifmsh->ps_peers_deep_sleep ? IEEE80211_MESHCONF_CAPAB_POWER_SAVE_LEVEL : 0x00; - *pos++ |= ifmsh->adjusting_tbtt ? - IEEE80211_MESHCONF_CAPAB_TBTT_ADJUSTING : 0x00; *pos++ = 0x00; return 0; @@ -866,7 +864,6 @@ int ieee80211_start_mesh(struct ieee8021 ifmsh->mesh_cc_id = 0; /* Disabled */ /* register sync ops from extensible synchronization framework */ ifmsh->sync_ops = ieee80211_mesh_sync_ops_get(ifmsh->mesh_sp_id); - ifmsh->adjusting_tbtt = false; ifmsh->sync_offset_clockdrift_max = 0; set_bit(MESH_WORK_HOUSEKEEPING, &ifmsh->wrkq_flags); ieee80211_mesh_root_setup(ifmsh); --- a/net/mac80211/mesh_sync.c +++ b/net/mac80211/mesh_sync.c @@ -119,7 +119,6 @@ static void mesh_sync_offset_rx_bcn_pres */ if (elems->mesh_config && mesh_peer_tbtt_adjusting(elems)) { - clear_sta_flag(sta, WLAN_STA_TOFFSET_KNOWN); msync_dbg(sdata, "STA %pM : is adjusting TBTT\n", sta->sta.addr); goto no_sync; @@ -168,11 +167,9 @@ static void mesh_sync_offset_adjust_tbtt struct beacon_data *beacon) { struct ieee80211_if_mesh *ifmsh = &sdata->u.mesh; - u8 cap; WARN_ON(ifmsh->mesh_sp_id != IEEE80211_SYNC_METHOD_NEIGHBOR_OFFSET); WARN_ON(!rcu_read_lock_held()); - cap = beacon->meshconf->meshconf_cap; spin_lock_bh(&ifmsh->sync_offset_lock); @@ -186,21 +183,13 @@ static void mesh_sync_offset_adjust_tbtt "TBTT : kicking off TBTT adjustment with clockdrift_max=%lld\n", ifmsh->sync_offset_clockdrift_max); set_bit(MESH_WORK_DRIFT_ADJUST, &ifmsh->wrkq_flags); - - ifmsh->adjusting_tbtt = true; } else { msync_dbg(sdata, "TBTT : max clockdrift=%lld; too small to adjust\n", (long long)ifmsh->sync_offset_clockdrift_max); ifmsh->sync_offset_clockdrift_max = 0; - - ifmsh->adjusting_tbtt = false; } spin_unlock_bh(&ifmsh->sync_offset_lock); - - beacon->meshconf->meshconf_cap = ifmsh->adjusting_tbtt ? - IEEE80211_MESHCONF_CAPAB_TBTT_ADJUSTING | cap : - ~IEEE80211_MESHCONF_CAPAB_TBTT_ADJUSTING & cap; } static const struct sync_method sync_methods[] = { Patches currently in stable-queue which might be from masashi.honma(a)gmail.com are queue-4.4/mac80211-suppress-new_peer_candidate-event-if-no-room.patch queue-4.4/mac80211-remove-invalid-flag-operations-in-mesh-tsf-synchronization.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "iio: light: fix improper return value" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled iio: light: fix improper return value to the 4.4-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-light-fix-improper-return-value.patch and it can be found in the queue-4.4 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 Tue Nov 28 10:56:34 CET 2017 From: Pan Bian <bianpan2016(a)163.com> Date: Sat, 3 Dec 2016 17:24:17 +0800 Subject: iio: light: fix improper return value From: Pan Bian <bianpan2016(a)163.com> [ Upstream commit db4e5376d058af8924fafd0520a0942d92538d0e ] In function cm3232_reg_init(), it returns 0 even if the last call to i2c_smbus_write_byte_data() returns a negative value (indicates error). As a result, the return value may be inconsistent with the execution status, and the caller of cm3232_reg_init() will not be able to detect the error. This patch fixes the bug. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=188641 Signed-off-by: Pan Bian <bianpan2016(a)163.com> Signed-off-by: Jonathan Cameron <jic23(a)kernel.org> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/iio/light/cm3232.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/iio/light/cm3232.c +++ b/drivers/iio/light/cm3232.c @@ -119,7 +119,7 @@ static int cm3232_reg_init(struct cm3232 if (ret < 0) dev_err(&chip->client->dev, "Error writing reg_cmd\n"); - return 0; + return ret; } /** Patches currently in stable-queue which might be from bianpan2016(a)163.com are queue-4.4/iio-light-fix-improper-return-value.patch queue-4.4/net-3com-typhoon-typhoon_init_one-fix-incorrect-return-values.patch queue-4.4/btrfs-return-the-actual-error-value-from-from-btrfs_uuid_tree_iterate.patch queue-4.4/staging-iio-cdc-fix-improper-return-value.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "drm/armada: Fix compile fail" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled drm/armada: Fix compile fail to the 4.4-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: drm-armada-fix-compile-fail.patch and it can be found in the queue-4.4 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 Tue Nov 28 10:56:34 CET 2017 From: Daniel Vetter <daniel.vetter(a)ffwll.ch> Date: Fri, 30 Dec 2016 17:38:52 +0100 Subject: drm/armada: Fix compile fail From: Daniel Vetter <daniel.vetter(a)ffwll.ch> [ Upstream commit 7357f89954b6d005df6ab8929759e78d7d9a80f9 ] I reported the include issue for tracepoints a while ago, but nothing seems to have happened. Now it bit us, since the drm_mm_print conversion was broken for armada. Fix it, so I can re-enable armada in the drm-misc build configs. v2: Rebase just the compile fix on top of Chris' build fix. Cc: Russell King <rmk+kernel(a)armlinux.org.uk> Cc: Chris Wilson <chris(a)chris-wilson.co.uk> Acked: Chris Wilson <chris(a)chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter(a)intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1483115932-19584-1-git-send-em… Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/gpu/drm/armada/Makefile | 2 ++ 1 file changed, 2 insertions(+) --- a/drivers/gpu/drm/armada/Makefile +++ b/drivers/gpu/drm/armada/Makefile @@ -4,3 +4,5 @@ armada-y += armada_510.o armada-$(CONFIG_DEBUG_FS) += armada_debugfs.o obj-$(CONFIG_DRM_ARMADA) := armada.o + +CFLAGS_armada_trace.o := -I$(src) Patches currently in stable-queue which might be from daniel.vetter(a)ffwll.ch are queue-4.4/drm-armada-fix-compile-fail.patch queue-4.4/drm-apply-range-restriction-after-color-adjustment-when-allocation.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "drm: Apply range restriction after color adjustment when allocation" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled drm: Apply range restriction after color adjustment when allocation to the 4.4-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: drm-apply-range-restriction-after-color-adjustment-when-allocation.patch and it can be found in the queue-4.4 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 Tue Nov 28 10:56:34 CET 2017 From: Chris Wilson <chris(a)chris-wilson.co.uk> Date: Thu, 22 Dec 2016 08:36:38 +0000 Subject: drm: Apply range restriction after color adjustment when allocation From: Chris Wilson <chris(a)chris-wilson.co.uk> [ Upstream commit 3db93756b501e5f0a3951c79cfa9ed43c26d3455 ] mm->color_adjust() compares the hole with its neighbouring nodes. They only abutt before we restrict the hole, so we have to apply color_adjust before we apply the range restriction. Signed-off-by: Chris Wilson <chris(a)chris-wilson.co.uk> Reviewed-by: Joonas Lahtinen <joonas.lahtinen(a)linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter(a)ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20161222083641.2691-36-chris@c… Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/gpu/drm/drm_mm.c | 16 ++++++---------- 1 file changed, 6 insertions(+), 10 deletions(-) --- a/drivers/gpu/drm/drm_mm.c +++ b/drivers/gpu/drm/drm_mm.c @@ -262,14 +262,12 @@ static void drm_mm_insert_helper_range(s BUG_ON(!hole_node->hole_follows || node->allocated); - if (adj_start < start) - adj_start = start; - if (adj_end > end) - adj_end = end; - if (mm->color_adjust) mm->color_adjust(hole_node, color, &adj_start, &adj_end); + adj_start = max(adj_start, start); + adj_end = min(adj_end, end); + if (flags & DRM_MM_CREATE_TOP) adj_start = adj_end - size; @@ -475,17 +473,15 @@ static struct drm_mm_node *drm_mm_search flags & DRM_MM_SEARCH_BELOW) { u64 hole_size = adj_end - adj_start; - if (adj_start < start) - adj_start = start; - if (adj_end > end) - adj_end = end; - if (mm->color_adjust) { mm->color_adjust(entry, color, &adj_start, &adj_end); if (adj_end <= adj_start) continue; } + adj_start = max(adj_start, start); + adj_end = min(adj_end, end); + if (!check_free_hole(adj_start, adj_end, size, alignment)) continue; Patches currently in stable-queue which might be from chris(a)chris-wilson.co.uk are queue-4.4/drm-armada-fix-compile-fail.patch queue-4.4/drm-apply-range-restriction-after-color-adjustment-when-allocation.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "dmaengine: zx: set DMA_CYCLIC cap_mask bit" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled dmaengine: zx: set DMA_CYCLIC cap_mask bit to the 4.4-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: dmaengine-zx-set-dma_cyclic-cap_mask-bit.patch and it can be found in the queue-4.4 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 Tue Nov 28 10:56:34 CET 2017 From: Shawn Guo <shawn.guo(a)linaro.org> Date: Thu, 15 Dec 2016 22:03:36 +0800 Subject: dmaengine: zx: set DMA_CYCLIC cap_mask bit From: Shawn Guo <shawn.guo(a)linaro.org> [ Upstream commit fc318d64f3d91e15babac00e08354b1beb650b57 ] The zx_dma driver supports cyclic transfer mode. Let's set DMA_CYCLIC cap_mask bit to make that clear, and avoid unnecessary failure when clients request channel via dma_request_chan_by_mask() with DMA_CYCLIC bit set in mask. Signed-off-by: Shawn Guo <shawn.guo(a)linaro.org> Reviewed-by: Jun Nie <jun.nie(a)linaro.org> Signed-off-by: Vinod Koul <vinod.koul(a)intel.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/dma/zx296702_dma.c | 1 + 1 file changed, 1 insertion(+) --- a/drivers/dma/zx296702_dma.c +++ b/drivers/dma/zx296702_dma.c @@ -813,6 +813,7 @@ static int zx_dma_probe(struct platform_ INIT_LIST_HEAD(&d->slave.channels); dma_cap_set(DMA_SLAVE, d->slave.cap_mask); dma_cap_set(DMA_MEMCPY, d->slave.cap_mask); + dma_cap_set(DMA_CYCLIC, d->slave.cap_mask); dma_cap_set(DMA_PRIVATE, d->slave.cap_mask); d->slave.dev = &op->dev; d->slave.device_free_chan_resources = zx_dma_free_chan_resources; Patches currently in stable-queue which might be from shawn.guo(a)linaro.org are queue-4.4/dmaengine-zx-set-dma_cyclic-cap_mask-bit.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "btrfs: return the actual error value from from btrfs_uuid_tree_iterate" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled btrfs: return the actual error value from from btrfs_uuid_tree_iterate to the 4.4-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: btrfs-return-the-actual-error-value-from-from-btrfs_uuid_tree_iterate.patch and it can be found in the queue-4.4 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 Tue Nov 28 10:56:34 CET 2017 From: Pan Bian <bianpan2016(a)163.com> Date: Sun, 4 Dec 2016 12:51:53 +0800 Subject: btrfs: return the actual error value from from btrfs_uuid_tree_iterate From: Pan Bian <bianpan2016(a)163.com> [ Upstream commit 73ba39ab9307340dc98ec3622891314bbc09cc2e ] In function btrfs_uuid_tree_iterate(), errno is assigned to variable ret on errors. However, it directly returns 0. It may be better to return ret. This patch also removes the warning, because the caller already prints a warning. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=188731 Signed-off-by: Pan Bian <bianpan2016(a)163.com> Reviewed-by: Omar Sandoval <osandov(a)fb.com> [ edited subject ] Signed-off-by: David Sterba <dsterba(a)suse.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/btrfs/uuid-tree.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) --- a/fs/btrfs/uuid-tree.c +++ b/fs/btrfs/uuid-tree.c @@ -348,7 +348,5 @@ skip: out: btrfs_free_path(path); - if (ret) - btrfs_warn(fs_info, "btrfs_uuid_tree_iterate failed %d", ret); - return 0; + return ret; } Patches currently in stable-queue which might be from bianpan2016(a)163.com are queue-4.4/iio-light-fix-improper-return-value.patch queue-4.4/net-3com-typhoon-typhoon_init_one-fix-incorrect-return-values.patch queue-4.4/btrfs-return-the-actual-error-value-from-from-btrfs_uuid_tree_iterate.patch queue-4.4/staging-iio-cdc-fix-improper-return-value.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "ath10k: set CTS protection VDEV param only if VDEV is up" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ath10k: set CTS protection VDEV param only if VDEV is up to the 4.4-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: ath10k-set-cts-protection-vdev-param-only-if-vdev-is-up.patch and it can be found in the queue-4.4 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 Tue Nov 28 10:56:34 CET 2017 From: Bartosz Markowski <bartosz.markowski(a)tieto.com> Date: Thu, 15 Dec 2016 11:23:24 +0200 Subject: ath10k: set CTS protection VDEV param only if VDEV is up From: Bartosz Markowski <bartosz.markowski(a)tieto.com> [ Upstream commit 7cfe0455ee1218add152e986b89b4bb8dbeafcdd ] The cts protection vdev parameter, in new QCA9377 TF2.0 firmware, requires bss peer to be created for the STATION vdev type. bss peer is being allocated by the firmware after vdev_start/_up commands. mac80211 may call the cts protection setup at any time, so the we needs to track the situation and defer the cts configuration to prevent firmware asserts, like below: [00]: 0x05020001 0x000015B3 0x0099ACE2 0x00955B31 [04]: 0x0099ACE2 0x00060730 0x00000004 0x00000000 [08]: 0x0044C754 0x00412C10 0x00000000 0x00409C54 [12]: 0x00000009 0x00000000 0x00952F6C 0x00952F77 [16]: 0x00952CC4 0x00910712 0x00000000 0x00000000 [20]: 0x4099ACE2 0x0040E858 0x00421254 0x004127F4 [24]: 0x8099B9B2 0x0040E8B8 0x00000000 0xC099ACE2 [28]: 0x800B75CB 0x0040E8F8 0x00000007 0x00005008 [32]: 0x809B048A 0x0040E958 0x00000010 0x00433B10 [36]: 0x809AFBBC 0x0040E9A8 0x0042BB74 0x0042BBBC [40]: 0x8091D252 0x0040E9C8 0x0042BBBC 0x00000001 [44]: 0x809FFA45 0x0040EA78 0x0043D3E4 0x0042C2C8 [48]: 0x809FCEF4 0x0040EA98 0x0043D3E4 0x00000001 [52]: 0x80911210 0x0040EAE8 0x00000010 0x004041D0 [56]: 0x80911154 0x0040EB28 0x00400000 0x00000000 Signed-off-by: Bartosz Markowski <bartosz.markowski(a)tieto.com> Signed-off-by: Kalle Valo <kvalo(a)qca.qualcomm.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/wireless/ath/ath10k/mac.c | 51 ++++++++++++++++++++++++++++------ 1 file changed, 43 insertions(+), 8 deletions(-) --- a/drivers/net/wireless/ath/ath10k/mac.c +++ b/drivers/net/wireless/ath/ath10k/mac.c @@ -1127,6 +1127,36 @@ static int ath10k_monitor_recalc(struct return ath10k_monitor_stop(ar); } +static bool ath10k_mac_can_set_cts_prot(struct ath10k_vif *arvif) +{ + struct ath10k *ar = arvif->ar; + + lockdep_assert_held(&ar->conf_mutex); + + if (!arvif->is_started) { + ath10k_dbg(ar, ATH10K_DBG_MAC, "defer cts setup, vdev is not ready yet\n"); + return false; + } + + return true; +} + +static int ath10k_mac_set_cts_prot(struct ath10k_vif *arvif) +{ + struct ath10k *ar = arvif->ar; + u32 vdev_param; + + lockdep_assert_held(&ar->conf_mutex); + + vdev_param = ar->wmi.vdev_param->protection_mode; + + ath10k_dbg(ar, ATH10K_DBG_MAC, "mac vdev %d cts_protection %d\n", + arvif->vdev_id, arvif->use_cts_prot); + + return ath10k_wmi_vdev_set_param(ar, arvif->vdev_id, vdev_param, + arvif->use_cts_prot ? 1 : 0); +} + static int ath10k_recalc_rtscts_prot(struct ath10k_vif *arvif) { struct ath10k *ar = arvif->ar; @@ -4788,20 +4818,18 @@ static void ath10k_bss_info_changed(stru if (changed & BSS_CHANGED_ERP_CTS_PROT) { arvif->use_cts_prot = info->use_cts_prot; - ath10k_dbg(ar, ATH10K_DBG_MAC, "mac vdev %d cts_prot %d\n", - arvif->vdev_id, info->use_cts_prot); ret = ath10k_recalc_rtscts_prot(arvif); if (ret) ath10k_warn(ar, "failed to recalculate rts/cts prot for vdev %d: %d\n", arvif->vdev_id, ret); - vdev_param = ar->wmi.vdev_param->protection_mode; - ret = ath10k_wmi_vdev_set_param(ar, arvif->vdev_id, vdev_param, - info->use_cts_prot ? 1 : 0); - if (ret) - ath10k_warn(ar, "failed to set protection mode %d on vdev %i: %d\n", - info->use_cts_prot, arvif->vdev_id, ret); + if (ath10k_mac_can_set_cts_prot(arvif)) { + ret = ath10k_mac_set_cts_prot(arvif); + if (ret) + ath10k_warn(ar, "failed to set cts protection for vdev %d: %d\n", + arvif->vdev_id, ret); + } } if (changed & BSS_CHANGED_ERP_SLOT) { @@ -6713,6 +6741,13 @@ ath10k_mac_op_assign_vif_chanctx(struct arvif->is_up = true; } + if (ath10k_mac_can_set_cts_prot(arvif)) { + ret = ath10k_mac_set_cts_prot(arvif); + if (ret) + ath10k_warn(ar, "failed to set cts protection for vdev %d: %d\n", + arvif->vdev_id, ret); + } + mutex_unlock(&ar->conf_mutex); return 0; Patches currently in stable-queue which might be from bartosz.markowski(a)tieto.com are queue-4.4/ath10k-set-cts-protection-vdev-param-only-if-vdev-is-up.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "ath10k: ignore configuring the incorrect board_id" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ath10k: ignore configuring the incorrect board_id to the 4.4-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: ath10k-ignore-configuring-the-incorrect-board_id.patch and it can be found in the queue-4.4 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 Tue Nov 28 10:56:34 CET 2017 From: Ryan Hsu <ryanhsu(a)qca.qualcomm.com> Date: Thu, 22 Dec 2016 15:02:37 -0800 Subject: ath10k: ignore configuring the incorrect board_id From: Ryan Hsu <ryanhsu(a)qca.qualcomm.com> [ Upstream commit d2e202c06ca42d353d95df12437740921a6d05b5 ] With command to get board_id from otp, in the case of following boot get otp board id result 0x00000000 board_id 0 chip_id 0 boot using board name 'bus=pci,bmi-chip-id=0,bmi-board-id=0" ... failed to fetch board data for bus=pci,bmi-chip-id=0,bmi-board-id=0 from ath10k/QCA6174/hw3.0/board-2.bin The invalid board_id=0 will be used as index to search in the board-2.bin. Ignore the case with board_id=0, as it means the otp is not carrying the board id information. Signed-off-by: Ryan Hsu <ryanhsu(a)qca.qualcomm.com> Signed-off-by: Kalle Valo <kvalo(a)qca.qualcomm.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/wireless/ath/ath10k/core.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) --- a/drivers/net/wireless/ath/ath10k/core.c +++ b/drivers/net/wireless/ath/ath10k/core.c @@ -548,8 +548,11 @@ static int ath10k_core_get_board_id_from "boot get otp board id result 0x%08x board_id %d chip_id %d\n", result, board_id, chip_id); - if ((result & ATH10K_BMI_BOARD_ID_STATUS_MASK) != 0) + if ((result & ATH10K_BMI_BOARD_ID_STATUS_MASK) != 0 || + (board_id == 0)) { + ath10k_warn(ar, "board id is not exist in otp, ignore it\n"); return -EOPNOTSUPP; + } ar->id.bmi_ids_valid = true; ar->id.bmi_board_id = board_id; Patches currently in stable-queue which might be from ryanhsu(a)qca.qualcomm.com are queue-4.4/ath10k-fix-incorrect-txpower-set-by-p2p_device-interface.patch queue-4.4/ath10k-ignore-configuring-the-incorrect-board_id.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "ath10k: fix potential memory leak in ath10k_wmi_tlv_op_pull_fw_stats()" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ath10k: fix potential memory leak in ath10k_wmi_tlv_op_pull_fw_stats() to the 4.4-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: ath10k-fix-potential-memory-leak-in-ath10k_wmi_tlv_op_pull_fw_stats.patch and it can be found in the queue-4.4 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 Tue Nov 28 10:56:34 CET 2017 From: Christian Lamparter <chunkeey(a)googlemail.com> Date: Thu, 29 Dec 2016 16:12:09 +0200 Subject: ath10k: fix potential memory leak in ath10k_wmi_tlv_op_pull_fw_stats() From: Christian Lamparter <chunkeey(a)googlemail.com> [ Upstream commit 097e46d2ae90265d1afe141ba6208ba598b79e01 ] ath10k_wmi_tlv_op_pull_fw_stats() uses tb = ath10k_wmi_tlv_parse_alloc(...) function, which allocates memory. If any of the three error-paths are taken, this tb needs to be freed. Signed-off-by: Christian Lamparter <chunkeey(a)googlemail.com> Signed-off-by: Kalle Valo <kvalo(a)qca.qualcomm.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/wireless/ath/ath10k/wmi-tlv.c | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) --- a/drivers/net/wireless/ath/ath10k/wmi-tlv.c +++ b/drivers/net/wireless/ath/ath10k/wmi-tlv.c @@ -1105,8 +1105,10 @@ static int ath10k_wmi_tlv_op_pull_fw_sta struct ath10k_fw_stats_pdev *dst; src = data; - if (data_len < sizeof(*src)) + if (data_len < sizeof(*src)) { + kfree(tb); return -EPROTO; + } data += sizeof(*src); data_len -= sizeof(*src); @@ -1126,8 +1128,10 @@ static int ath10k_wmi_tlv_op_pull_fw_sta struct ath10k_fw_stats_vdev *dst; src = data; - if (data_len < sizeof(*src)) + if (data_len < sizeof(*src)) { + kfree(tb); return -EPROTO; + } data += sizeof(*src); data_len -= sizeof(*src); @@ -1145,8 +1149,10 @@ static int ath10k_wmi_tlv_op_pull_fw_sta struct ath10k_fw_stats_peer *dst; src = data; - if (data_len < sizeof(*src)) + if (data_len < sizeof(*src)) { + kfree(tb); return -EPROTO; + } data += sizeof(*src); data_len -= sizeof(*src); Patches currently in stable-queue which might be from chunkeey(a)googlemail.com are queue-4.4/ath10k-fix-potential-memory-leak-in-ath10k_wmi_tlv_op_pull_fw_stats.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "ath10k: fix incorrect txpower set by P2P_DEVICE interface" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ath10k: fix incorrect txpower set by P2P_DEVICE interface to the 4.4-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: ath10k-fix-incorrect-txpower-set-by-p2p_device-interface.patch and it can be found in the queue-4.4 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 Tue Nov 28 10:56:34 CET 2017 From: Ryan Hsu <ryanhsu(a)qca.qualcomm.com> Date: Tue, 13 Dec 2016 14:55:19 -0800 Subject: ath10k: fix incorrect txpower set by P2P_DEVICE interface From: Ryan Hsu <ryanhsu(a)qca.qualcomm.com> [ Upstream commit 88407beb1b1462f706a1950a355fd086e1c450b6 ] Ath10k reports the phy capability that supports P2P_DEVICE interface. When we use the P2P supported wpa_supplicant to start connection, it'll create two interfaces, one is wlan0 (vdev_id=0) and one is P2P_DEVICE p2p-dev-wlan0 which is for p2p control channel (vdev_id=1). ath10k_pci mac vdev create 0 (add interface) type 2 subtype 0 ath10k_add_interface: vdev_id: 0, txpower: 0, bss_power: 0 ... ath10k_pci mac vdev create 1 (add interface) type 2 subtype 1 ath10k_add_interface: vdev_id: 1, txpower: 0, bss_power: 0 And the txpower in per vif bss_conf will only be set to valid tx power when the interface is assigned with channel_ctx. But this P2P_DEVICE interface will never be used for any connection, so that the uninitialized bss_conf.txpower=0 is assinged to the arvif->txpower when interface created. Since the txpower configuration is firmware per physical interface. So the smallest txpower of all vifs will be the one limit the tx power of the physical device, that causing the low txpower issue on other active interfaces. wlan0: Limiting TX power to 21 (24 - 3) dBm ath10k_pci mac vdev_id 0 txpower 21 ath10k_mac_txpower_recalc: vdev_id: 1, txpower: 0 ath10k_mac_txpower_recalc: vdev_id: 0, txpower: 21 ath10k_pci mac txpower 0 This issue only happens when we use the wpa_supplicant that supports P2P or if we use the iw tool to create the control P2P_DEVICE interface. Signed-off-by: Ryan Hsu <ryanhsu(a)qca.qualcomm.com> Signed-off-by: Kalle Valo <kvalo(a)qca.qualcomm.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/wireless/ath/ath10k/mac.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) --- a/drivers/net/wireless/ath/ath10k/mac.c +++ b/drivers/net/wireless/ath/ath10k/mac.c @@ -4180,7 +4180,8 @@ static int ath10k_mac_txpower_recalc(str lockdep_assert_held(&ar->conf_mutex); list_for_each_entry(arvif, &ar->arvifs, list) { - WARN_ON(arvif->txpower < 0); + if (arvif->txpower <= 0) + continue; if (txpower == -1) txpower = arvif->txpower; @@ -4188,8 +4189,8 @@ static int ath10k_mac_txpower_recalc(str txpower = min(txpower, arvif->txpower); } - if (WARN_ON(txpower == -1)) - return -EINVAL; + if (txpower == -1) + return 0; ret = ath10k_mac_txpower_setup(ar, txpower); if (ret) { Patches currently in stable-queue which might be from ryanhsu(a)qca.qualcomm.com are queue-4.4/ath10k-fix-incorrect-txpower-set-by-p2p_device-interface.patch queue-4.4/ath10k-ignore-configuring-the-incorrect-board_id.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "ASoC: wm_adsp: Don't overrun firmware file buffer when reading region data" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ASoC: wm_adsp: Don't overrun firmware file buffer when reading region data to the 4.4-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: asoc-wm_adsp-don-t-overrun-firmware-file-buffer-when-reading-region-data.patch and it can be found in the queue-4.4 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 Tue Nov 28 10:56:34 CET 2017 From: Richard Fitzgerald <rf(a)opensource.wolfsonmicro.com> Date: Tue, 20 Dec 2016 10:29:12 +0000 Subject: ASoC: wm_adsp: Don't overrun firmware file buffer when reading region data From: Richard Fitzgerald <rf(a)opensource.wolfsonmicro.com> [ Upstream commit 1cab2a84f470e15ecc8e5143bfe9398c6e888032 ] Protect against corrupt firmware files by ensuring that the length we get for the data in a region actually lies within the available firmware file data buffer. Signed-off-by: Richard Fitzgerald <rf(a)opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- sound/soc/codecs/wm_adsp.c | 25 ++++++++++++++++++++++++- 1 file changed, 24 insertions(+), 1 deletion(-) --- a/sound/soc/codecs/wm_adsp.c +++ b/sound/soc/codecs/wm_adsp.c @@ -1060,7 +1060,7 @@ static int wm_adsp_load(struct wm_adsp * const struct wmfw_region *region; const struct wm_adsp_region *mem; const char *region_name; - char *file, *text; + char *file, *text = NULL; struct wm_adsp_buf *buf; unsigned int reg; int regions = 0; @@ -1221,10 +1221,21 @@ static int wm_adsp_load(struct wm_adsp * regions, le32_to_cpu(region->len), offset, region_name); + if ((pos + le32_to_cpu(region->len) + sizeof(*region)) > + firmware->size) { + adsp_err(dsp, + "%s.%d: %s region len %d bytes exceeds file length %zu\n", + file, regions, region_name, + le32_to_cpu(region->len), firmware->size); + ret = -EINVAL; + goto out_fw; + } + if (text) { memcpy(text, region->data, le32_to_cpu(region->len)); adsp_info(dsp, "%s: %s\n", file, text); kfree(text); + text = NULL; } if (reg) { @@ -1269,6 +1280,7 @@ out_fw: regmap_async_complete(regmap); wm_adsp_buf_free(&buf_list); release_firmware(firmware); + kfree(text); out: kfree(file); @@ -1730,6 +1742,17 @@ static int wm_adsp_load_coeff(struct wm_ } if (reg) { + if ((pos + le32_to_cpu(blk->len) + sizeof(*blk)) > + firmware->size) { + adsp_err(dsp, + "%s.%d: %s region len %d bytes exceeds file length %zu\n", + file, blocks, region_name, + le32_to_cpu(blk->len), + firmware->size); + ret = -EINVAL; + goto out_fw; + } + buf = wm_adsp_buf_alloc(blk->data, le32_to_cpu(blk->len), &buf_list); Patches currently in stable-queue which might be from rf(a)opensource.wolfsonmicro.com are queue-4.4/asoc-wm_adsp-don-t-overrun-firmware-file-buffer-when-reading-region-data.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "ASoC: rsnd: don't double free kctrl" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ASoC: rsnd: don't double free kctrl to the 4.4-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: asoc-rsnd-don-t-double-free-kctrl.patch and it can be found in the queue-4.4 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 Tue Nov 28 10:56:34 CET 2017 From: Colin Ian King <colin.king(a)canonical.com> Date: Thu, 8 Dec 2016 13:05:43 +0000 Subject: ASoC: rsnd: don't double free kctrl From: Colin Ian King <colin.king(a)canonical.com> [ Upstream commit 0ea617a298dcdc2251b4e10f83ac3f3e627b66e3 ] On an error, snd_ctl_add already free's kctrl, so calling snd_ctl_free_one to free it again leads to a double free error. Fix this by removing the extraneous snd_ctl_free_one call. Issue found using static analysis with CoverityScan, CID 1372908 Signed-off-by: Colin Ian King <colin.king(a)canonical.com> Acked-by: Kuninori Morimoto <kuninori.morimoto.gx(a)renesas.com> Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- sound/soc/sh/rcar/core.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) --- a/sound/soc/sh/rcar/core.c +++ b/sound/soc/sh/rcar/core.c @@ -1049,10 +1049,8 @@ static int __rsnd_kctrl_new(struct rsnd_ return -ENOMEM; ret = snd_ctl_add(card, kctrl); - if (ret < 0) { - snd_ctl_free_one(kctrl); + if (ret < 0) return ret; - } cfg->update = update; cfg->card = card; Patches currently in stable-queue which might be from colin.king(a)canonical.com are queue-4.4/asoc-rsnd-don-t-double-free-kctrl.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "ALSA: hda - Apply ALC269_FIXUP_NO_SHUTUP on HDA_FIXUP_ACT_PROBE" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ALSA: hda - Apply ALC269_FIXUP_NO_SHUTUP on HDA_FIXUP_ACT_PROBE to the 4.4-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: alsa-hda-apply-alc269_fixup_no_shutup-on-hda_fixup_act_probe.patch and it can be found in the queue-4.4 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 Tue Nov 28 10:56:34 CET 2017 From: Gabriele Mazzotta <gabriele.mzt(a)gmail.com> Date: Sat, 24 Dec 2016 19:50:00 +0100 Subject: ALSA: hda - Apply ALC269_FIXUP_NO_SHUTUP on HDA_FIXUP_ACT_PROBE From: Gabriele Mazzotta <gabriele.mzt(a)gmail.com> [ Upstream commit 972aa2c708703c21f14eb958b37e82aae2530e44 ] Setting shutup when the action is HDA_FIXUP_ACT_PRE_PROBE might not have the desired effect since it could be overridden by another more generic shutup function. Prevent this by setting the more specific shutup function on HDA_FIXUP_ACT_PROBE. Signed-off-by: Gabriele Mazzotta <gabriele.mzt(a)gmail.com> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- sound/pci/hda/patch_realtek.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -4404,7 +4404,7 @@ static void alc_no_shutup(struct hda_cod static void alc_fixup_no_shutup(struct hda_codec *codec, const struct hda_fixup *fix, int action) { - if (action == HDA_FIXUP_ACT_PRE_PROBE) { + if (action == HDA_FIXUP_ACT_PROBE) { struct alc_spec *spec = codec->spec; spec->shutup = alc_no_shutup; } Patches currently in stable-queue which might be from gabriele.mzt(a)gmail.com are queue-4.4/alsa-hda-apply-alc269_fixup_no_shutup-on-hda_fixup_act_probe.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] [GIT PULL] commits for Linux 4.9

by alexander.levin＠verizon.com

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi Greg, Pleae pull commits for Linux 4.9 . I've sent a review request for all commits over a week ago and all comments were addressed. Thanks, Sasha ===== The following changes since commit 133e6ccf46f1704a4a680ef45565e970ac9a7f9c: Linux 4.9.65 (2017-11-24 08:33:43 +0100) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/sashal/linux-stable.git for-greg-4.9-2 for you to fetch changes up to 4497679088e98b2098974b8e2512928cb848c610: xen: xenbus driver must not accept invalid transaction ids (2017-11-24 10:49:54 -0500) - ---------------------------------------------------------------- Abhishek Sahu (1): clk: qcom: ipq4019: Add all the frequencies for apss cpu Alexey Khoroshilov (1): adm80211: add checks for dma mapping errors Amitkumar Karwar (1): mwifiex: sdio: fix use after free issue for save_adapter Avinash Repaka (1): RDS: make message size limit compliant with spec Bartosz Golaszewski (1): gpio: mockup: dynamically allocate memory for chip name Bartosz Markowski (1): ath10k: set CTS protection VDEV param only if VDEV is up Bjorn Helgaas (1): PCI: Apply _HPX settings only to relevant devices Chris Wilson (1): drm: Apply range restriction after color adjustment when allocation Christian Lamparter (1): ath10k: fix potential memory leak in ath10k_wmi_tlv_op_pull_fw_stats() Christophe JAILLET (2): drm/sun4i: Fix a return value in case of error pinctrl: sirf: atlas7: Add missing 'of_node_put()' Colin Ian King (1): ASoC: rsnd: don't double free kctrl Dan Carpenter (1): adm80211: return an error if adm8211_alloc_rings() fails Daniel Verkamp (1): nvmet: fix KATO offset in Set Features Daniel Vetter (2): drm/armada: Fix compile fail drm/mediatek: don't use drm_put_dev David Ahern (1): net: Allow IP_MULTICAST_IF to set index to L3 slave Eric Biggers (2): fscrypt: use ENOKEY when file cannot be created w/o key fscrypt: use ENOTDIR when setting encryption policy on nondirectory Florian Westphal (1): netfilter: nf_tables: fix oob access Gabriele Mazzotta (1): ALSA: hda - Apply ALC269_FIXUP_NO_SHUTUP on HDA_FIXUP_ACT_PROBE Geert Uytterhoeven (1): spi: SPI_FSL_DSPI should depend on HAS_DMA Hans Verkuil (3): [media] cec: when canceling a message, don't overwrite old status info [media] cec: CEC_MSG_GIVE_FEATURES should abort for CEC version < 2 [media] cec: update log_addr[] before finishing configuration Heiko Carstens (1): s390/kbuild: enable modversions for symbols exported from asm Icenowy Zheng (1): clk: sunxi-ng: fix PLL_CPUX adjusting on A33 Juergen Gross (1): xen: xenbus driver must not accept invalid transaction ids Maarten Lankhorst (1): drm/atomic: Unconditionally call prepare_fb. Marcus Cooper (1): clk: sunxi-ng: A31: Fix spdif clock register Masashi Honma (2): mac80211: Remove invalid flag operations in mesh TSF synchronization mac80211: Suppress NEW_PEER_CANDIDATE event if no room Michael Chan (1): bnxt_en: Set default completion ring for async events. Pablo Neira Ayuso (1): netfilter: nft_queue: use raw_smp_processor_id() Pan Bian (3): iio: light: fix improper return value staging: iio: cdc: fix improper return value btrfs: return the actual error value from from btrfs_uuid_tree_iterate Richard Fitzgerald (1): ASoC: wm_adsp: Don't overrun firmware file buffer when reading region data Romain Perier (1): crypto: marvell - Copy IVDIG before launching partial DMA ahash requests Ryan Hsu (2): ath10k: fix incorrect txpower set by P2P_DEVICE interface ath10k: ignore configuring the incorrect board_id Santosh Shilimkar (2): RDS: RDMA: return appropriate error on rdma map failures RDS: RDMA: fix the ib_map_mr_sg_zbva() argument Shawn Guo (1): dmaengine: zx: set DMA_CYCLIC cap_mask bit Stanislaw Gruszka (1): rt2800: set minimum MPDU and PSDU lengths to sane values Thomas Preisner (2): net: 3com: typhoon: typhoon_init_one: make return values more specific net: 3com: typhoon: typhoon_init_one: fix incorrect return values Vincente Tsou (1): drm/915: Parsing the missed out DTD fields from the VBT arch/s390/include/asm/asm-prototypes.h | 8 ++++ drivers/clk/qcom/gcc-ipq4019.c | 14 ++++++- drivers/clk/sunxi-ng/ccu-sun6i-a31.c | 4 +- drivers/clk/sunxi-ng/ccu-sun8i-a33.c | 10 +++++ drivers/crypto/marvell/cesa.h | 3 +- drivers/crypto/marvell/hash.c | 34 ++++++++++++++- drivers/crypto/marvell/tdma.c | 9 +++- drivers/dma/zx296702_dma.c | 1 + drivers/gpio/gpio-mockup.c | 10 +++-- drivers/gpu/drm/armada/Makefile | 2 + drivers/gpu/drm/drm_atomic_helper.c | 9 ---- drivers/gpu/drm/drm_mm.c | 16 +++---- drivers/gpu/drm/i915/intel_bios.c | 8 ++-- drivers/gpu/drm/i915/intel_vbt_defs.h | 12 +++--- drivers/gpu/drm/mediatek/mtk_drm_drv.c | 3 +- drivers/gpu/drm/sun4i/sun4i_backend.c | 2 +- drivers/iio/light/cm3232.c | 2 +- drivers/net/ethernet/3com/typhoon.c | 25 ++++++----- drivers/net/ethernet/broadcom/bnxt/bnxt.c | 30 +++++++++++++ drivers/net/wireless/admtek/adm8211.c | 27 ++++++++++-- drivers/net/wireless/ath/ath10k/core.c | 5 ++- drivers/net/wireless/ath/ath10k/mac.c | 58 +++++++++++++++++++++----- drivers/net/wireless/ath/ath10k/wmi-tlv.c | 12 ++++-- drivers/net/wireless/marvell/mwifiex/sdio.c | 6 +++ drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 4 +- drivers/nvme/target/admin-cmd.c | 4 +- drivers/pci/probe.c | 15 ++++++- drivers/pinctrl/sirf/pinctrl-atlas7.c | 7 ++-- drivers/spi/Kconfig | 1 + drivers/staging/iio/cdc/ad7150.c | 2 +- drivers/staging/media/cec/cec-adap.c | 16 +++---- drivers/xen/xenbus/xenbus_dev_frontend.c | 2 +- fs/btrfs/uuid-tree.c | 4 +- fs/crypto/fname.c | 4 +- fs/crypto/policy.c | 2 +- fs/ext4/ialloc.c | 2 +- fs/ext4/namei.c | 4 +- fs/f2fs/dir.c | 5 ++- fs/f2fs/namei.c | 4 +- net/ipv4/ip_sockglue.c | 7 +++- net/ipv6/ipv6_sockglue.c | 16 +++++-- net/mac80211/ieee80211_i.h | 1 - net/mac80211/mesh.c | 3 -- net/mac80211/mesh_plink.c | 14 ++++--- net/mac80211/mesh_sync.c | 11 ----- net/netfilter/nf_tables_api.c | 2 +- net/netfilter/nft_queue.c | 2 +- net/rds/ib_frmr.c | 5 ++- net/rds/rdma.c | 9 +++- net/rds/rds.h | 3 ++ net/rds/send.c | 42 ++++++++++++++++++- sound/pci/hda/patch_realtek.c | 2 +- sound/soc/codecs/wm_adsp.c | 25 ++++++++++- sound/soc/sh/rcar/core.c | 4 +- 54 files changed, 395 insertions(+), 137 deletions(-) create mode 100644 arch/s390/include/asm/asm-prototypes.h -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJaGFNmAAoJEN6mb/eXdyzcbLEQAI2n31H8UmkP22ZcSGuPKVCU tUzJP+ibvvUCHd6X6mYvyQajmVLMS9EH09ZI88zOoolTmuT7xwATDd32rY80mZBo 4sq2bT/LskT9V8lTgbq700l1i7ZnOFxyO4fPS/DIT8udTQKzi1zX5uZfokn4Ldqz NU2h7qgZ7/gf1DmqiZ4Slo1fNaVdjPyu/qsCzjN/MV+t7uy3Riqoz3MiWbCF1ATL v4Jrp41K/jhRIhtD6TmgrtRR8dJTb6DkVw40UcOvZMtoSHn24Q4hVmKdVwPapqFT GSnpjrIZ8bShVlEIhCtMkb/ZaZKWj6jivg5Em7FqPrtsM+VIYBbN3jyxQ9yBItyb AdmlQEBKpuUfxsD1n3O5gAqzC4Eqg5ovHWXMzB3i2/8RqkOWev18N3OA9fi2GS/y dOV2yNSDSvqZW84JVtmYO1FWsp5XcOZZaSrVSlyxg0KBZkFQIrx+i2t2Y+G8R9pa AVKrhCDXcosyPzGzEgUNPYJa89yOv9K8ui9T0OKa2UIw8mi8TIsHvdnfzjarOe+X m1YcbFWGsnyejSPsR27ZdOTgChcfAx+U8qTBHRgEQSu2GukNXGyr5hV2bbD42YuO Kb8LhLbuqFUdevsfBTKjZkCEcmSrNdJomdBe3pW1ZgPV3y6X+7ocWJS407cP3NPr PjxT69oVf2y4ZqDAdUGF =fu7K -----END PGP SIGNATURE-----

7 years, 5 months

2
1
0 0

[Linux-stable-mirror] Patch "xen: xenbus driver must not accept invalid transaction ids" 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 xen: xenbus driver must not accept invalid transaction ids 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: xen-xenbus-driver-must-not-accept-invalid-transaction-ids.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 Tue Nov 28 10:49:28 CET 2017 From: Juergen Gross <jgross(a)suse.com> Date: Thu, 22 Dec 2016 08:19:46 +0100 Subject: xen: xenbus driver must not accept invalid transaction ids From: Juergen Gross <jgross(a)suse.com> [ Upstream commit 639b08810d6ad74ded2c5f6e233c4fcb9d147168 ] When accessing Xenstore in a transaction the user is specifying a transaction id which he normally obtained from Xenstore when starting the transaction. Xenstore is validating a transaction id against all known transaction ids of the connection the request came in. As all requests of a domain not being the one where Xenstore lives share one connection, validation of transaction ids of different users of Xenstore in that domain should be done by the kernel of that domain being the multiplexer between the Xenstore users in that domain and Xenstore. In order to prohibit one Xenstore user "hijacking" a transaction from another user the xenbus driver has to verify a given transaction id against all known transaction ids of the user before forwarding it to Xenstore. Signed-off-by: Juergen Gross <jgross(a)suse.com> Reviewed-by: Boris Ostrovsky <boris.ostrovsky(a)oracle.com> Signed-off-by: Juergen Gross <jgross(a)suse.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/xen/xenbus/xenbus_dev_frontend.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/xen/xenbus/xenbus_dev_frontend.c +++ b/drivers/xen/xenbus/xenbus_dev_frontend.c @@ -316,7 +316,7 @@ static int xenbus_write_transaction(unsi rc = -ENOMEM; goto out; } - } else if (msg_type == XS_TRANSACTION_END) { + } else if (u->u.msg.tx_id != 0) { list_for_each_entry(trans, &u->transactions, list) if (trans->handle.id == u->u.msg.tx_id) break; Patches currently in stable-queue which might be from jgross(a)suse.com are queue-4.9/xen-xenbus-driver-must-not-accept-invalid-transaction-ids.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "staging: iio: cdc: fix improper return 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 staging: iio: cdc: fix improper return 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: staging-iio-cdc-fix-improper-return-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 Tue Nov 28 10:49:28 CET 2017 From: Pan Bian <bianpan2016(a)163.com> Date: Sat, 3 Dec 2016 21:44:30 +0800 Subject: staging: iio: cdc: fix improper return value From: Pan Bian <bianpan2016(a)163.com> [ Upstream commit 91ca1a8c584f55857b1f6ab20a1d3a1ce7a559bb ] At the end of function ad7150_write_event_config(), directly returns 0. As a result, the errors will be ignored by the callers. It may be better to return variable "ret". Signed-off-by: Pan Bian <bianpan2016(a)163.com> Signed-off-by: Jonathan Cameron <jic23(a)kernel.org> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/staging/iio/cdc/ad7150.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/staging/iio/cdc/ad7150.c +++ b/drivers/staging/iio/cdc/ad7150.c @@ -274,7 +274,7 @@ static int ad7150_write_event_config(str error_ret: mutex_unlock(&chip->state_lock); - return 0; + return ret; } static int ad7150_read_event_value(struct iio_dev *indio_dev, Patches currently in stable-queue which might be from bianpan2016(a)163.com are queue-4.9/iio-light-fix-improper-return-value.patch queue-4.9/net-3com-typhoon-typhoon_init_one-fix-incorrect-return-values.patch queue-4.9/btrfs-return-the-actual-error-value-from-from-btrfs_uuid_tree_iterate.patch queue-4.9/staging-iio-cdc-fix-improper-return-value.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "spi: SPI_FSL_DSPI should depend on HAS_DMA" 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 spi: SPI_FSL_DSPI should depend on HAS_DMA 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: spi-spi_fsl_dspi-should-depend-on-has_dma.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 Tue Nov 28 10:49:28 CET 2017 From: Geert Uytterhoeven <geert(a)linux-m68k.org> Date: Wed, 14 Dec 2016 13:28:05 +0100 Subject: spi: SPI_FSL_DSPI should depend on HAS_DMA From: Geert Uytterhoeven <geert(a)linux-m68k.org> [ Upstream commit dadab2d4e3cf708ceba22ecddd94aedfecb39199 ] If NO_DMA=y: ERROR: "bad_dma_ops" [drivers/spi/spi-fsl-dspi.ko] undefined! Add a dependency on HAS_DMA to fix this. Signed-off-by: Geert Uytterhoeven <geert(a)linux-m68k.org> Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/spi/Kconfig | 1 + 1 file changed, 1 insertion(+) --- a/drivers/spi/Kconfig +++ b/drivers/spi/Kconfig @@ -365,6 +365,7 @@ config SPI_FSL_SPI config SPI_FSL_DSPI tristate "Freescale DSPI controller" select REGMAP_MMIO + depends on HAS_DMA depends on SOC_VF610 || SOC_LS1021A || ARCH_LAYERSCAPE || COMPILE_TEST help This enables support for the Freescale DSPI controller in master Patches currently in stable-queue which might be from geert(a)linux-m68k.org are queue-4.9/spi-spi_fsl_dspi-should-depend-on-has_dma.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "s390/kbuild: enable modversions for symbols exported from asm" 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 s390/kbuild: enable modversions for symbols exported from asm 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: s390-kbuild-enable-modversions-for-symbols-exported-from-asm.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 Tue Nov 28 10:49:28 CET 2017 From: Heiko Carstens <heiko.carstens(a)de.ibm.com> Date: Tue, 20 Dec 2016 12:58:10 +0100 Subject: s390/kbuild: enable modversions for symbols exported from asm From: Heiko Carstens <heiko.carstens(a)de.ibm.com> [ Upstream commit cabab3f9f5ca077535080b3252e6168935b914af ] s390 version of commit 334bb7738764 ("x86/kbuild: enable modversions for symbols exported from asm") so we get also rid of all these warnings: WARNING: EXPORT symbol "_mcount" [vmlinux] version generation failed, symbol will not be versioned. WARNING: EXPORT symbol "memcpy" [vmlinux] version generation failed, symbol will not be versioned. WARNING: EXPORT symbol "memmove" [vmlinux] version generation failed, symbol will not be versioned. WARNING: EXPORT symbol "memset" [vmlinux] version generation failed, symbol will not be versioned. WARNING: EXPORT symbol "save_fpu_regs" [vmlinux] version generation failed, symbol will not be versioned. WARNING: EXPORT symbol "sie64a" [vmlinux] version generation failed, symbol will not be versioned. WARNING: EXPORT symbol "sie_exit" [vmlinux] version generation failed, symbol will not be versioned. Signed-off-by: Heiko Carstens <heiko.carstens(a)de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky(a)de.ibm.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/s390/include/asm/asm-prototypes.h | 8 ++++++++ 1 file changed, 8 insertions(+) create mode 100644 arch/s390/include/asm/asm-prototypes.h --- /dev/null +++ b/arch/s390/include/asm/asm-prototypes.h @@ -0,0 +1,8 @@ +#ifndef _ASM_S390_PROTOTYPES_H + +#include <linux/kvm_host.h> +#include <linux/ftrace.h> +#include <asm/fpu/api.h> +#include <asm-generic/asm-prototypes.h> + +#endif /* _ASM_S390_PROTOTYPES_H */ Patches currently in stable-queue which might be from heiko.carstens(a)de.ibm.com are queue-4.9/s390-disassembler-add-missing-end-marker-for-e7-table.patch queue-4.9/s390-kbuild-enable-modversions-for-symbols-exported-from-asm.patch queue-4.9/s390-fix-transactional-execution-control-register-handling.patch queue-4.9/s390-runtime-instrumention-fix-possible-memory-corruption.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "rt2800: set minimum MPDU and PSDU lengths to sane values" 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 rt2800: set minimum MPDU and PSDU lengths to sane values 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: rt2800-set-minimum-mpdu-and-psdu-lengths-to-sane-values.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 Tue Nov 28 10:49:28 CET 2017 From: Stanislaw Gruszka <sgruszka(a)redhat.com> Date: Mon, 19 Dec 2016 11:52:49 +0100 Subject: rt2800: set minimum MPDU and PSDU lengths to sane values From: Stanislaw Gruszka <sgruszka(a)redhat.com> [ Upstream commit a51b89698ccc93c7e274eb71377fae49c4593ab2 ] Signed-off-by: Stanislaw Gruszka <sgruszka(a)redhat.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/ralink/rt2x00/rt2800lib.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c +++ b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c @@ -4707,8 +4707,8 @@ static int rt2800_init_registers(struct rt2x00_set_field32(&reg, MAX_LEN_CFG_MAX_PSDU, 2); else rt2x00_set_field32(&reg, MAX_LEN_CFG_MAX_PSDU, 1); - rt2x00_set_field32(&reg, MAX_LEN_CFG_MIN_PSDU, 0); - rt2x00_set_field32(&reg, MAX_LEN_CFG_MIN_MPDU, 0); + rt2x00_set_field32(&reg, MAX_LEN_CFG_MIN_PSDU, 10); + rt2x00_set_field32(&reg, MAX_LEN_CFG_MIN_MPDU, 10); rt2800_register_write(rt2x00dev, MAX_LEN_CFG, reg); rt2800_register_read(rt2x00dev, LED_CFG, &reg); Patches currently in stable-queue which might be from sgruszka(a)redhat.com are queue-4.9/rt2800-set-minimum-mpdu-and-psdu-lengths-to-sane-values.patch queue-4.9/rt2x00usb-mark-device-removed-when-get-enoent-usb-error.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "RDS: RDMA: return appropriate error on rdma map failures" 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 RDS: RDMA: return appropriate error on rdma map failures 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: rds-rdma-return-appropriate-error-on-rdma-map-failures.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 Tue Nov 28 10:49:28 CET 2017 From: Santosh Shilimkar <santosh.shilimkar(a)oracle.com> Date: Mon, 4 Jul 2016 17:04:37 -0700 Subject: RDS: RDMA: return appropriate error on rdma map failures From: Santosh Shilimkar <santosh.shilimkar(a)oracle.com> [ Upstream commit 584a8279a44a800dea5a5c1e9d53a002e03016b4 ] The first message to a remote node should prompt a new connection even if it is RDMA operation. For RDMA operation the MR mapping can fail because connections is not yet up. Since the connection establishment is asynchronous, we make sure the map failure because of unavailable connection reach to the user by appropriate error code. Before returning to the user, lets trigger the connection so that its ready for the next retry. Signed-off-by: Santosh Shilimkar <santosh.shilimkar(a)oracle.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/rds/send.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) --- a/net/rds/send.c +++ b/net/rds/send.c @@ -946,6 +946,11 @@ static int rds_cmsg_send(struct rds_sock ret = rds_cmsg_rdma_map(rs, rm, cmsg); if (!ret) *allocated_mr = 1; + else if (ret == -ENODEV) + /* Accommodate the get_mr() case which can fail + * if connection isn't established yet. + */ + ret = -EAGAIN; break; case RDS_CMSG_ATOMIC_CSWP: case RDS_CMSG_ATOMIC_FADD: @@ -1114,8 +1119,12 @@ int rds_sendmsg(struct socket *sock, str /* Parse any control messages the user may have included. */ ret = rds_cmsg_send(rs, rm, msg, &allocated_mr); - if (ret) + if (ret) { + /* Trigger connection so that its ready for the next retry */ + if (ret == -EAGAIN) + rds_conn_connect_if_down(conn); goto out; + } if (rm->rdma.op_active && !conn->c_trans->xmit_rdma) { printk_ratelimited(KERN_NOTICE "rdma_op %p conn xmit_rdma %p\n", Patches currently in stable-queue which might be from santosh.shilimkar(a)oracle.com are queue-4.9/rds-make-message-size-limit-compliant-with-spec.patch queue-4.9/rds-rdma-return-appropriate-error-on-rdma-map-failures.patch queue-4.9/rds-rdma-fix-the-ib_map_mr_sg_zbva-argument.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "RDS: RDMA: fix the ib_map_mr_sg_zbva() argument" 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 RDS: RDMA: fix the ib_map_mr_sg_zbva() argument 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: rds-rdma-fix-the-ib_map_mr_sg_zbva-argument.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 Tue Nov 28 10:49:28 CET 2017 From: Santosh Shilimkar <santosh.shilimkar(a)oracle.com> Date: Sun, 4 Dec 2016 16:25:43 -0800 Subject: RDS: RDMA: fix the ib_map_mr_sg_zbva() argument From: Santosh Shilimkar <santosh.shilimkar(a)oracle.com> [ Upstream commit 3e56c2f856d7aba6a03feea834d68f9c05f7d0b6 ] Fixes warning: Using plain integer as NULL pointer Signed-off-by: Santosh Shilimkar <santosh.shilimkar(a)oracle.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/rds/ib_frmr.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) --- a/net/rds/ib_frmr.c +++ b/net/rds/ib_frmr.c @@ -104,14 +104,15 @@ static int rds_ib_post_reg_frmr(struct r struct rds_ib_frmr *frmr = &ibmr->u.frmr; struct ib_send_wr *failed_wr; struct ib_reg_wr reg_wr; - int ret; + int ret, off = 0; while (atomic_dec_return(&ibmr->ic->i_fastreg_wrs) <= 0) { atomic_inc(&ibmr->ic->i_fastreg_wrs); cpu_relax(); } - ret = ib_map_mr_sg_zbva(frmr->mr, ibmr->sg, ibmr->sg_len, 0, PAGE_SIZE); + ret = ib_map_mr_sg_zbva(frmr->mr, ibmr->sg, ibmr->sg_len, + &off, PAGE_SIZE); if (unlikely(ret != ibmr->sg_len)) return ret < 0 ? ret : -EINVAL; Patches currently in stable-queue which might be from santosh.shilimkar(a)oracle.com are queue-4.9/rds-make-message-size-limit-compliant-with-spec.patch queue-4.9/rds-rdma-return-appropriate-error-on-rdma-map-failures.patch queue-4.9/rds-rdma-fix-the-ib_map_mr_sg_zbva-argument.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "RDS: make message size limit compliant with spec" 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 RDS: make message size limit compliant with spec 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: rds-make-message-size-limit-compliant-with-spec.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 Tue Nov 28 10:49:28 CET 2017 From: Avinash Repaka <avinash.repaka(a)oracle.com> Date: Mon, 29 Feb 2016 15:30:57 -0800 Subject: RDS: make message size limit compliant with spec From: Avinash Repaka <avinash.repaka(a)oracle.com> [ Upstream commit f9fb69adb6c7acca60977a4db5a5f95b8e66c041 ] RDS support max message size as 1M but the code doesn't check this in all cases. Patch fixes it for RDMA & non-RDMA and RDS MR size and its enforced irrespective of underlying transport. Signed-off-by: Avinash Repaka <avinash.repaka(a)oracle.com> Signed-off-by: Santosh Shilimkar <santosh.shilimkar(a)oracle.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/rds/rdma.c | 9 ++++++++- net/rds/rds.h | 3 +++ net/rds/send.c | 31 +++++++++++++++++++++++++++++++ 3 files changed, 42 insertions(+), 1 deletion(-) --- a/net/rds/rdma.c +++ b/net/rds/rdma.c @@ -40,7 +40,6 @@ /* * XXX * - build with sparse - * - should we limit the size of a mr region? let transport return failure? * - should we detect duplicate keys on a socket? hmm. * - an rdma is an mlock, apply rlimit? */ @@ -200,6 +199,14 @@ static int __rds_rdma_map(struct rds_soc goto out; } + /* Restrict the size of mr irrespective of underlying transport + * To account for unaligned mr regions, subtract one from nr_pages + */ + if ((nr_pages - 1) > (RDS_MAX_MSG_SIZE >> PAGE_SHIFT)) { + ret = -EMSGSIZE; + goto out; + } + rdsdebug("RDS: get_mr addr %llx len %llu nr_pages %u\n", args->vec.addr, args->vec.bytes, nr_pages); --- a/net/rds/rds.h +++ b/net/rds/rds.h @@ -50,6 +50,9 @@ void rdsdebug(char *fmt, ...) #define RDS_FRAG_SHIFT 12 #define RDS_FRAG_SIZE ((unsigned int)(1 << RDS_FRAG_SHIFT)) +/* Used to limit both RDMA and non-RDMA RDS message to 1MB */ +#define RDS_MAX_MSG_SIZE ((unsigned int)(1 << 20)) + #define RDS_CONG_MAP_BYTES (65536 / 8) #define RDS_CONG_MAP_PAGES (PAGE_ALIGN(RDS_CONG_MAP_BYTES) / PAGE_SIZE) #define RDS_CONG_MAP_PAGE_BITS (PAGE_SIZE * 8) --- a/net/rds/send.c +++ b/net/rds/send.c @@ -988,6 +988,26 @@ static int rds_send_mprds_hash(struct rd return hash; } +static int rds_rdma_bytes(struct msghdr *msg, size_t *rdma_bytes) +{ + struct rds_rdma_args *args; + struct cmsghdr *cmsg; + + for_each_cmsghdr(cmsg, msg) { + if (!CMSG_OK(msg, cmsg)) + return -EINVAL; + + if (cmsg->cmsg_level != SOL_RDS) + continue; + + if (cmsg->cmsg_type == RDS_CMSG_RDMA_ARGS) { + args = CMSG_DATA(cmsg); + *rdma_bytes += args->remote_vec.bytes; + } + } + return 0; +} + int rds_sendmsg(struct socket *sock, struct msghdr *msg, size_t payload_len) { struct sock *sk = sock->sk; @@ -1002,6 +1022,7 @@ int rds_sendmsg(struct socket *sock, str int nonblock = msg->msg_flags & MSG_DONTWAIT; long timeo = sock_sndtimeo(sk, nonblock); struct rds_conn_path *cpath; + size_t total_payload_len = payload_len, rdma_payload_len = 0; /* Mirror Linux UDP mirror of BSD error message compatibility */ /* XXX: Perhaps MSG_MORE someday */ @@ -1034,6 +1055,16 @@ int rds_sendmsg(struct socket *sock, str } release_sock(sk); + ret = rds_rdma_bytes(msg, &rdma_payload_len); + if (ret) + goto out; + + total_payload_len += rdma_payload_len; + if (max_t(size_t, payload_len, rdma_payload_len) > RDS_MAX_MSG_SIZE) { + ret = -EMSGSIZE; + goto out; + } + if (payload_len > rds_sk_sndbuf(rs)) { ret = -EMSGSIZE; goto out; Patches currently in stable-queue which might be from avinash.repaka(a)oracle.com are queue-4.9/rds-make-message-size-limit-compliant-with-spec.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "pinctrl: sirf: atlas7: Add missing 'of_node_put()'" 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 pinctrl: sirf: atlas7: Add missing 'of_node_put()' 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: pinctrl-sirf-atlas7-add-missing-of_node_put.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 Tue Nov 28 10:49:28 CET 2017 From: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr> Date: Tue, 20 Dec 2016 06:40:43 +0100 Subject: pinctrl: sirf: atlas7: Add missing 'of_node_put()' From: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr> [ Upstream commit 7af355e6715b325d8af29822f4c3dbecd7eeebec ] Reference to 'sys2pci_np' should be dropped in all cases here, not only in error handling path. Signed-off-by: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr> Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/pinctrl/sirf/pinctrl-atlas7.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) --- a/drivers/pinctrl/sirf/pinctrl-atlas7.c +++ b/drivers/pinctrl/sirf/pinctrl-atlas7.c @@ -5420,14 +5420,15 @@ static int atlas7_pinmux_probe(struct pl sys2pci_np = of_find_node_by_name(NULL, "sys2pci"); if (!sys2pci_np) return -EINVAL; + ret = of_address_to_resource(sys2pci_np, 0, &res); + of_node_put(sys2pci_np); if (ret) return ret; + pmx->sys2pci_base = devm_ioremap_resource(&pdev->dev, &res); - if (IS_ERR(pmx->sys2pci_base)) { - of_node_put(sys2pci_np); + if (IS_ERR(pmx->sys2pci_base)) return -ENOMEM; - } pmx->dev = &pdev->dev; Patches currently in stable-queue which might be from christophe.jaillet(a)wanadoo.fr are queue-4.9/drm-sun4i-fix-a-return-value-in-case-of-error.patch queue-4.9/pinctrl-sirf-atlas7-add-missing-of_node_put.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "PCI: Apply _HPX settings only to relevant devices" 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 PCI: Apply _HPX settings only to relevant devices 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: pci-apply-_hpx-settings-only-to-relevant-devices.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 Tue Nov 28 10:49:28 CET 2017 From: Bjorn Helgaas <bhelgaas(a)google.com> Date: Mon, 2 Jan 2017 14:04:24 -0600 Subject: PCI: Apply _HPX settings only to relevant devices From: Bjorn Helgaas <bhelgaas(a)google.com> [ Upstream commit 977509f7c5c6fb992ffcdf4291051af343b91645 ] Previously we didn't check the type of device before trying to apply Type 1 (PCI-X) or Type 2 (PCIe) Setting Records from _HPX. We don't support PCI-X Setting Records, so this was harmless, but the warning was useless. We do support PCIe Setting Records, and we didn't check whether a device was PCIe before applying settings. I don't think anything bad happened on non-PCIe devices because pcie_capability_clear_and_set_word(), pcie_cap_has_lnkctl(), etc., would fail before doing any harm. But it's ugly to depend on those internals. Check the device type before attempting to apply Type 1 and Type 2 Setting Records (Type 0 records are applicable to PCI, PCI-X, and PCIe devices). A side benefit is that this prevents useless "not supported" warnings when a BIOS supplies a Type 1 (PCI-X) Setting Record and we try to apply it to every single device: pci 0000:00:00.0: PCI-X settings not supported After this patch, we'll get the warning only when a BIOS supplies a Type 1 record and we have a PCI-X device to which it should be applied. Link: https://bugzilla.kernel.org/show_bug.cgi?id=187731 Signed-off-by: Bjorn Helgaas <bhelgaas(a)google.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/pci/probe.c | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-) --- a/drivers/pci/probe.c +++ b/drivers/pci/probe.c @@ -1438,8 +1438,16 @@ static void program_hpp_type0(struct pci static void program_hpp_type1(struct pci_dev *dev, struct hpp_type1 *hpp) { - if (hpp) - dev_warn(&dev->dev, "PCI-X settings not supported\n"); + int pos; + + if (!hpp) + return; + + pos = pci_find_capability(dev, PCI_CAP_ID_PCIX); + if (!pos) + return; + + dev_warn(&dev->dev, "PCI-X settings not supported\n"); } static bool pcie_root_rcb_set(struct pci_dev *dev) @@ -1465,6 +1473,9 @@ static void program_hpp_type2(struct pci if (!hpp) return; + if (!pci_is_pcie(dev)) + return; + if (hpp->revision > 1) { dev_warn(&dev->dev, "PCIe settings rev %d not supported\n", hpp->revision); Patches currently in stable-queue which might be from bhelgaas(a)google.com are queue-4.9/pci-apply-_hpx-settings-only-to-relevant-devices.patch queue-4.9/pci-set-cavium-acs-capability-quirk-flags-to-assert-rr-cr-sv-uf.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "nvmet: fix KATO offset in Set Features" 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 nvmet: fix KATO offset in Set Features 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: nvmet-fix-kato-offset-in-set-features.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 Tue Nov 28 10:49:28 CET 2017 From: Daniel Verkamp <daniel.verkamp(a)intel.com> Date: Fri, 9 Dec 2016 12:59:46 -0700 Subject: nvmet: fix KATO offset in Set Features From: Daniel Verkamp <daniel.verkamp(a)intel.com> [ Upstream commit 6c73f949300f17851f53fa80c9d1611ccd6909d3 ] The Set Features implementation for Keep Alive Timer was using the wrong structure when retrieving the KATO value; it was treating the Set Features command as a Property Set command. The NVMe spec defines the Keep Alive Timer feature as having one input in CDW11 (4 bytes at offset 44 in the command) whereas the code was reading 8 bytes at offset 48. Since the Linux NVMe over Fabrics host never sets this feature, this code has presumably never been tested. Signed-off-by: Daniel Verkamp <daniel.verkamp(a)intel.com> Signed-off-by: Christoph Hellwig <hch(a)lst.de> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/nvme/target/admin-cmd.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) --- a/drivers/nvme/target/admin-cmd.c +++ b/drivers/nvme/target/admin-cmd.c @@ -381,7 +381,6 @@ static void nvmet_execute_set_features(s { struct nvmet_subsys *subsys = req->sq->ctrl->subsys; u32 cdw10 = le32_to_cpu(req->cmd->common.cdw10[0]); - u64 val; u32 val32; u16 status = 0; @@ -391,8 +390,7 @@ static void nvmet_execute_set_features(s (subsys->max_qid - 1) | ((subsys->max_qid - 1) << 16)); break; case NVME_FEAT_KATO: - val = le64_to_cpu(req->cmd->prop_set.value); - val32 = val & 0xffff; + val32 = le32_to_cpu(req->cmd->common.cdw10[1]); req->sq->ctrl->kato = DIV_ROUND_UP(val32, 1000); nvmet_set_result(req, req->sq->ctrl->kato); break; Patches currently in stable-queue which might be from daniel.verkamp(a)intel.com are queue-4.9/nvmet-fix-kato-offset-in-set-features.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "netfilter: nft_queue: use raw_smp_processor_id()" 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 netfilter: nft_queue: use raw_smp_processor_id() 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: netfilter-nft_queue-use-raw_smp_processor_id.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 Tue Nov 28 10:49:28 CET 2017 From: Pablo Neira Ayuso <pablo(a)netfilter.org> Date: Sun, 11 Dec 2016 20:46:51 +0100 Subject: netfilter: nft_queue: use raw_smp_processor_id() From: Pablo Neira Ayuso <pablo(a)netfilter.org> [ Upstream commit c2e756ff9e699865d294cdc112acfc36419cf5cc ] Using smp_processor_id() causes splats with PREEMPT_RCU: [19379.552780] BUG: using smp_processor_id() in preemptible [00000000] code: ping/32389 [19379.552793] caller is debug_smp_processor_id+0x17/0x19 [...] [19379.552823] Call Trace: [19379.552832] [<ffffffff81274e9e>] dump_stack+0x67/0x90 [19379.552837] [<ffffffff8129a4d4>] check_preemption_disabled+0xe5/0xf5 [19379.552842] [<ffffffff8129a4fb>] debug_smp_processor_id+0x17/0x19 [19379.552849] [<ffffffffa07c42dd>] nft_queue_eval+0x35/0x20c [nft_queue] No need to disable preemption since we only fetch the numeric value, so let's use raw_smp_processor_id() instead. Signed-off-by: Pablo Neira Ayuso <pablo(a)netfilter.org> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/netfilter/nft_queue.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/net/netfilter/nft_queue.c +++ b/net/netfilter/nft_queue.c @@ -38,7 +38,7 @@ static void nft_queue_eval(const struct if (priv->queues_total > 1) { if (priv->flags & NFT_QUEUE_FLAG_CPU_FANOUT) { - int cpu = smp_processor_id(); + int cpu = raw_smp_processor_id(); queue = priv->queuenum + cpu % priv->queues_total; } else { Patches currently in stable-queue which might be from pablo(a)netfilter.org are queue-4.9/netfilter-nf_tables-fix-oob-access.patch queue-4.9/netfilter-nft_queue-use-raw_smp_processor_id.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "netfilter: nf_tables: fix oob access" 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 netfilter: nf_tables: fix oob access 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: netfilter-nf_tables-fix-oob-access.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 Tue Nov 28 10:49:28 CET 2017 From: Florian Westphal <fw(a)strlen.de> Date: Tue, 13 Dec 2016 13:59:33 +0100 Subject: netfilter: nf_tables: fix oob access From: Florian Westphal <fw(a)strlen.de> [ Upstream commit 3e38df136e453aa69eb4472108ebce2fb00b1ba6 ] BUG: KASAN: slab-out-of-bounds in nf_tables_rule_destroy+0xf1/0x130 at addr ffff88006a4c35c8 Read of size 8 by task nft/1607 When we've destroyed last valid expr, nft_expr_next() returns an invalid expr. We must not dereference it unless it passes != nft_expr_last() check. Signed-off-by: Florian Westphal <fw(a)strlen.de> Signed-off-by: Pablo Neira Ayuso <pablo(a)netfilter.org> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/netfilter/nf_tables_api.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/net/netfilter/nf_tables_api.c +++ b/net/netfilter/nf_tables_api.c @@ -2068,7 +2068,7 @@ static void nf_tables_rule_destroy(const * is called on error from nf_tables_newrule(). */ expr = nft_expr_first(rule); - while (expr->ops && expr != nft_expr_last(rule)) { + while (expr != nft_expr_last(rule) && expr->ops) { nf_tables_expr_destroy(ctx, expr); expr = nft_expr_next(expr); } Patches currently in stable-queue which might be from fw(a)strlen.de are queue-4.9/netfilter-nf_tables-fix-oob-access.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "net: Allow IP_MULTICAST_IF to set index to L3 slave" 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 net: Allow IP_MULTICAST_IF to set index to L3 slave 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: net-allow-ip_multicast_if-to-set-index-to-l3-slave.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 Tue Nov 28 10:49:28 CET 2017 From: David Ahern <dsa(a)cumulusnetworks.com> Date: Thu, 29 Dec 2016 15:39:37 -0800 Subject: net: Allow IP_MULTICAST_IF to set index to L3 slave From: David Ahern <dsa(a)cumulusnetworks.com> [ Upstream commit 7bb387c5ab12aeac3d5eea28686489ff46b53ca9 ] IP_MULTICAST_IF fails if sk_bound_dev_if is already set and the new index does not match it. e.g., ntpd[15381]: setsockopt IP_MULTICAST_IF 192.168.1.23 fails: Invalid argument Relax the check in setsockopt to allow setting mc_index to an L3 slave if sk_bound_dev_if points to an L3 master. Make a similar change for IPv6. In this case change the device lookup to take the rcu_read_lock avoiding a refcnt. The rcu lock is also needed for the lookup of a potential L3 master device. This really only silences a setsockopt failure since uses of mc_index are secondary to sk_bound_dev_if if it is set. In both cases, if either index is an L3 slave or master, lookups are directed to the same FIB table so relaxing the check at setsockopt time causes no harm. Patch is based on a suggested change by Darwin for a problem noted in their code base. Suggested-by: Darwin Dingel <darwin.dingel(a)alliedtelesis.co.nz> Signed-off-by: David Ahern <dsa(a)cumulusnetworks.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> --- net/ipv4/ip_sockglue.c | 7 ++++++- net/ipv6/ipv6_sockglue.c | 16 ++++++++++++---- 2 files changed, 18 insertions(+), 5 deletions(-) --- a/net/ipv4/ip_sockglue.c +++ b/net/ipv4/ip_sockglue.c @@ -819,6 +819,7 @@ static int do_ip_setsockopt(struct sock { struct ip_mreqn mreq; struct net_device *dev = NULL; + int midx; if (sk->sk_type == SOCK_STREAM) goto e_inval; @@ -863,11 +864,15 @@ static int do_ip_setsockopt(struct sock err = -EADDRNOTAVAIL; if (!dev) break; + + midx = l3mdev_master_ifindex(dev); + dev_put(dev); err = -EINVAL; if (sk->sk_bound_dev_if && - mreq.imr_ifindex != sk->sk_bound_dev_if) + mreq.imr_ifindex != sk->sk_bound_dev_if && + (!midx || midx != sk->sk_bound_dev_if)) break; inet->mc_index = mreq.imr_ifindex; --- a/net/ipv6/ipv6_sockglue.c +++ b/net/ipv6/ipv6_sockglue.c @@ -585,16 +585,24 @@ done: if (val) { struct net_device *dev; + int midx; - if (sk->sk_bound_dev_if && sk->sk_bound_dev_if != val) - goto e_inval; + rcu_read_lock(); - dev = dev_get_by_index(net, val); + dev = dev_get_by_index_rcu(net, val); if (!dev) { + rcu_read_unlock(); retv = -ENODEV; break; } - dev_put(dev); + midx = l3mdev_master_ifindex_rcu(dev); + + rcu_read_unlock(); + + if (sk->sk_bound_dev_if && + sk->sk_bound_dev_if != val && + (!midx || midx != sk->sk_bound_dev_if)) + goto e_inval; } np->mcast_oif = val; retv = 0; Patches currently in stable-queue which might be from dsa(a)cumulusnetworks.com are queue-4.9/net-allow-ip_multicast_if-to-set-index-to-l3-slave.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "net: 3com: typhoon: typhoon_init_one: make return values more specific" 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 net: 3com: typhoon: typhoon_init_one: make return values more specific 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: net-3com-typhoon-typhoon_init_one-make-return-values-more-specific.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 Tue Nov 28 10:49:28 CET 2017 From: Thomas Preisner <thomas.preisner+linux(a)fau.de> Date: Fri, 30 Dec 2016 03:37:54 +0100 Subject: net: 3com: typhoon: typhoon_init_one: make return values more specific From: Thomas Preisner <thomas.preisner+linux(a)fau.de> [ Upstream commit 6b6bbb5922a4b1d4b58125a572da91010295fba3 ] In some cases the return value of a failing function is not being used and the function typhoon_init_one() returns another negative error code instead. Signed-off-by: Thomas Preisner <thomas.preisner+linux(a)fau.de> Signed-off-by: Milan Stephan <milan.stephan+linux(a)fau.de> 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/3com/typhoon.c | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) --- a/drivers/net/ethernet/3com/typhoon.c +++ b/drivers/net/ethernet/3com/typhoon.c @@ -2366,9 +2366,9 @@ typhoon_init_one(struct pci_dev *pdev, c * 4) Get the hardware address. * 5) Put the card to sleep. */ - if (typhoon_reset(ioaddr, WaitSleep) < 0) { + err = typhoon_reset(ioaddr, WaitSleep); + if (err < 0) { err_msg = "could not reset 3XP"; - err = -EIO; goto error_out_dma; } @@ -2382,16 +2382,16 @@ typhoon_init_one(struct pci_dev *pdev, c typhoon_init_interface(tp); typhoon_init_rings(tp); - if(typhoon_boot_3XP(tp, TYPHOON_STATUS_WAITING_FOR_HOST) < 0) { + err = typhoon_boot_3XP(tp, TYPHOON_STATUS_WAITING_FOR_HOST); + if (err < 0) { err_msg = "cannot boot 3XP sleep image"; - err = -EIO; goto error_out_reset; } INIT_COMMAND_WITH_RESPONSE(&xp_cmd, TYPHOON_CMD_READ_MAC_ADDRESS); - if(typhoon_issue_command(tp, 1, &xp_cmd, 1, xp_resp) < 0) { + err = typhoon_issue_command(tp, 1, &xp_cmd, 1, xp_resp); + if (err < 0) { err_msg = "cannot read MAC address"; - err = -EIO; goto error_out_reset; } @@ -2424,9 +2424,9 @@ typhoon_init_one(struct pci_dev *pdev, c if(xp_resp[0].numDesc != 0) tp->capabilities |= TYPHOON_WAKEUP_NEEDS_RESET; - if(typhoon_sleep(tp, PCI_D3hot, 0) < 0) { + err = typhoon_sleep(tp, PCI_D3hot, 0); + if (err < 0) { err_msg = "cannot put adapter to sleep"; - err = -EIO; goto error_out_reset; } Patches currently in stable-queue which might be from thomas.preisner+linux(a)fau.de are queue-4.9/net-3com-typhoon-typhoon_init_one-fix-incorrect-return-values.patch queue-4.9/net-3com-typhoon-typhoon_init_one-make-return-values-more-specific.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "net: 3com: typhoon: typhoon_init_one: fix incorrect return values" 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 net: 3com: typhoon: typhoon_init_one: fix incorrect return values 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: net-3com-typhoon-typhoon_init_one-fix-incorrect-return-values.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 Tue Nov 28 10:49:28 CET 2017 From: Thomas Preisner <thomas.preisner+linux(a)fau.de> Date: Fri, 30 Dec 2016 03:37:53 +0100 Subject: net: 3com: typhoon: typhoon_init_one: fix incorrect return values From: Thomas Preisner <thomas.preisner+linux(a)fau.de> [ Upstream commit 107fded7bf616ad6f46823d98b8ed6405d7adf2d ] In a few cases the err-variable is not set to a negative error code if a function call in typhoon_init_one() fails and thus 0 is returned instead. It may be better to set err to the appropriate negative error code before returning. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=188841 Reported-by: Pan Bian <bianpan2016(a)163.com> Signed-off-by: Thomas Preisner <thomas.preisner+linux(a)fau.de> Signed-off-by: Milan Stephan <milan.stephan+linux(a)fau.de> 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/3com/typhoon.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) --- a/drivers/net/ethernet/3com/typhoon.c +++ b/drivers/net/ethernet/3com/typhoon.c @@ -2398,8 +2398,9 @@ typhoon_init_one(struct pci_dev *pdev, c *(__be16 *)&dev->dev_addr[0] = htons(le16_to_cpu(xp_resp[0].parm1)); *(__be32 *)&dev->dev_addr[2] = htonl(le32_to_cpu(xp_resp[0].parm2)); - if(!is_valid_ether_addr(dev->dev_addr)) { + if (!is_valid_ether_addr(dev->dev_addr)) { err_msg = "Could not obtain valid ethernet address, aborting"; + err = -EIO; goto error_out_reset; } @@ -2407,7 +2408,8 @@ typhoon_init_one(struct pci_dev *pdev, c * later when we print out the version reported. */ INIT_COMMAND_WITH_RESPONSE(&xp_cmd, TYPHOON_CMD_READ_VERSIONS); - if(typhoon_issue_command(tp, 1, &xp_cmd, 3, xp_resp) < 0) { + err = typhoon_issue_command(tp, 1, &xp_cmd, 3, xp_resp); + if (err < 0) { err_msg = "Could not get Sleep Image version"; goto error_out_reset; } @@ -2449,7 +2451,8 @@ typhoon_init_one(struct pci_dev *pdev, c dev->features = dev->hw_features | NETIF_F_HW_VLAN_CTAG_RX | NETIF_F_RXCSUM; - if(register_netdev(dev) < 0) { + err = register_netdev(dev); + if (err < 0) { err_msg = "unable to register netdev"; goto error_out_reset; } Patches currently in stable-queue which might be from thomas.preisner+linux(a)fau.de are queue-4.9/net-3com-typhoon-typhoon_init_one-fix-incorrect-return-values.patch queue-4.9/net-3com-typhoon-typhoon_init_one-make-return-values-more-specific.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "mwifiex: sdio: fix use after free issue for save_adapter" 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 mwifiex: sdio: fix use after free issue for save_adapter 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: mwifiex-sdio-fix-use-after-free-issue-for-save_adapter.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 Tue Nov 28 10:49:28 CET 2017 From: Amitkumar Karwar <akarwar(a)marvell.com> Date: Thu, 1 Dec 2016 19:23:31 +0530 Subject: mwifiex: sdio: fix use after free issue for save_adapter From: Amitkumar Karwar <akarwar(a)marvell.com> [ Upstream commit 74c8719b8ee0922593a5cbec0bd6127d86d8a2f4 ] If we have sdio work requests received when sdio card reset is happening, we may end up accessing older save_adapter pointer later which is already freed during card reset. This patch solves the problem by cancelling those pending requests. Signed-off-by: Amitkumar Karwar <akarwar(a)marvell.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/marvell/mwifiex/sdio.c | 6 ++++++ 1 file changed, 6 insertions(+) --- a/drivers/net/wireless/marvell/mwifiex/sdio.c +++ b/drivers/net/wireless/marvell/mwifiex/sdio.c @@ -2296,6 +2296,12 @@ static void mwifiex_recreate_adapter(str mmc_hw_reset(func->card->host); sdio_release_host(func); + /* Previous save_adapter won't be valid after this. We will cancel + * pending work requests. + */ + clear_bit(MWIFIEX_IFACE_WORK_DEVICE_DUMP, &iface_work_flags); + clear_bit(MWIFIEX_IFACE_WORK_CARD_RESET, &iface_work_flags); + mwifiex_sdio_probe(func, device_id); } Patches currently in stable-queue which might be from akarwar(a)marvell.com are queue-4.9/mwifiex-sdio-fix-use-after-free-issue-for-save_adapter.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "mac80211: Suppress NEW_PEER_CANDIDATE event if no room" 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 mac80211: Suppress NEW_PEER_CANDIDATE event if no room 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: mac80211-suppress-new_peer_candidate-event-if-no-room.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 Tue Nov 28 10:49:28 CET 2017 From: Masashi Honma <masashi.honma(a)gmail.com> Date: Wed, 30 Nov 2016 09:06:04 +0900 Subject: mac80211: Suppress NEW_PEER_CANDIDATE event if no room From: Masashi Honma <masashi.honma(a)gmail.com> [ Upstream commit 11197d006bcfabf0173a7820a163fcaac420d10e ] Previously, kernel sends NEW_PEER_CANDIDATE event to user land even if the found peer does not have any room to accept other peer. This causes continuous connection trials. Signed-off-by: Masashi Honma <masashi.honma(a)gmail.com> Signed-off-by: Johannes Berg <johannes.berg(a)intel.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/mac80211/mesh_plink.c | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) --- a/net/mac80211/mesh_plink.c +++ b/net/mac80211/mesh_plink.c @@ -505,12 +505,14 @@ mesh_sta_info_alloc(struct ieee80211_sub /* Userspace handles station allocation */ if (sdata->u.mesh.user_mpm || - sdata->u.mesh.security & IEEE80211_MESH_SEC_AUTHED) - cfg80211_notify_new_peer_candidate(sdata->dev, addr, - elems->ie_start, - elems->total_len, - GFP_KERNEL); - else + sdata->u.mesh.security & IEEE80211_MESH_SEC_AUTHED) { + if (mesh_peer_accepts_plinks(elems) && + mesh_plink_availables(sdata)) + cfg80211_notify_new_peer_candidate(sdata->dev, addr, + elems->ie_start, + elems->total_len, + GFP_KERNEL); + } else sta = __mesh_sta_info_alloc(sdata, addr); return sta; Patches currently in stable-queue which might be from masashi.honma(a)gmail.com are queue-4.9/mac80211-suppress-new_peer_candidate-event-if-no-room.patch queue-4.9/mac80211-remove-invalid-flag-operations-in-mesh-tsf-synchronization.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "mac80211: Remove invalid flag operations in mesh TSF synchronization" 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 mac80211: Remove invalid flag operations in mesh TSF synchronization 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: mac80211-remove-invalid-flag-operations-in-mesh-tsf-synchronization.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 Tue Nov 28 10:49:28 CET 2017 From: Masashi Honma <masashi.honma(a)gmail.com> Date: Thu, 8 Dec 2016 10:15:50 +0900 Subject: mac80211: Remove invalid flag operations in mesh TSF synchronization From: Masashi Honma <masashi.honma(a)gmail.com> [ Upstream commit 76f43b4c0a9337af22827d78de4f2b8fd5328489 ] mesh_sync_offset_adjust_tbtt() implements Extensible synchronization framework ([1] 13.13.2 Extensible synchronization framework). It shall not operate the flag "TBTT Adjusting subfield" ([1] 8.4.2.100.8 Mesh Capability), since it is used only for MBCA ([1] 13.13.4 Mesh beacon collision avoidance, see 13.13.4.4.3 TBTT scanning and adjustment procedures for detail). So this patch remove the flag operations. [1] IEEE Std 802.11 2012 Signed-off-by: Masashi Honma <masashi.honma(a)gmail.com> [remove adjusting_tbtt entirely, since it's now unused] Signed-off-by: Johannes Berg <johannes.berg(a)intel.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/mac80211/ieee80211_i.h | 1 - net/mac80211/mesh.c | 3 --- net/mac80211/mesh_sync.c | 11 ----------- 3 files changed, 15 deletions(-) --- a/net/mac80211/ieee80211_i.h +++ b/net/mac80211/ieee80211_i.h @@ -681,7 +681,6 @@ struct ieee80211_if_mesh { const struct ieee80211_mesh_sync_ops *sync_ops; s64 sync_offset_clockdrift_max; spinlock_t sync_offset_lock; - bool adjusting_tbtt; /* mesh power save */ enum nl80211_mesh_power_mode nonpeer_pm; int ps_peers_light_sleep; --- a/net/mac80211/mesh.c +++ b/net/mac80211/mesh.c @@ -279,8 +279,6 @@ int mesh_add_meshconf_ie(struct ieee8021 /* Mesh PS mode. See IEEE802.11-2012 8.4.2.100.8 */ *pos |= ifmsh->ps_peers_deep_sleep ? IEEE80211_MESHCONF_CAPAB_POWER_SAVE_LEVEL : 0x00; - *pos++ |= ifmsh->adjusting_tbtt ? - IEEE80211_MESHCONF_CAPAB_TBTT_ADJUSTING : 0x00; *pos++ = 0x00; return 0; @@ -850,7 +848,6 @@ int ieee80211_start_mesh(struct ieee8021 ifmsh->mesh_cc_id = 0; /* Disabled */ /* register sync ops from extensible synchronization framework */ ifmsh->sync_ops = ieee80211_mesh_sync_ops_get(ifmsh->mesh_sp_id); - ifmsh->adjusting_tbtt = false; ifmsh->sync_offset_clockdrift_max = 0; set_bit(MESH_WORK_HOUSEKEEPING, &ifmsh->wrkq_flags); ieee80211_mesh_root_setup(ifmsh); --- a/net/mac80211/mesh_sync.c +++ b/net/mac80211/mesh_sync.c @@ -123,7 +123,6 @@ static void mesh_sync_offset_rx_bcn_pres */ if (elems->mesh_config && mesh_peer_tbtt_adjusting(elems)) { - clear_sta_flag(sta, WLAN_STA_TOFFSET_KNOWN); msync_dbg(sdata, "STA %pM : is adjusting TBTT\n", sta->sta.addr); goto no_sync; @@ -172,11 +171,9 @@ static void mesh_sync_offset_adjust_tbtt struct beacon_data *beacon) { struct ieee80211_if_mesh *ifmsh = &sdata->u.mesh; - u8 cap; WARN_ON(ifmsh->mesh_sp_id != IEEE80211_SYNC_METHOD_NEIGHBOR_OFFSET); WARN_ON(!rcu_read_lock_held()); - cap = beacon->meshconf->meshconf_cap; spin_lock_bh(&ifmsh->sync_offset_lock); @@ -190,21 +187,13 @@ static void mesh_sync_offset_adjust_tbtt "TBTT : kicking off TBTT adjustment with clockdrift_max=%lld\n", ifmsh->sync_offset_clockdrift_max); set_bit(MESH_WORK_DRIFT_ADJUST, &ifmsh->wrkq_flags); - - ifmsh->adjusting_tbtt = true; } else { msync_dbg(sdata, "TBTT : max clockdrift=%lld; too small to adjust\n", (long long)ifmsh->sync_offset_clockdrift_max); ifmsh->sync_offset_clockdrift_max = 0; - - ifmsh->adjusting_tbtt = false; } spin_unlock_bh(&ifmsh->sync_offset_lock); - - beacon->meshconf->meshconf_cap = ifmsh->adjusting_tbtt ? - IEEE80211_MESHCONF_CAPAB_TBTT_ADJUSTING | cap : - ~IEEE80211_MESHCONF_CAPAB_TBTT_ADJUSTING & cap; } static const struct sync_method sync_methods[] = { Patches currently in stable-queue which might be from masashi.honma(a)gmail.com are queue-4.9/mac80211-suppress-new_peer_candidate-event-if-no-room.patch queue-4.9/mac80211-remove-invalid-flag-operations-in-mesh-tsf-synchronization.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "iio: light: fix improper return 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: light: fix improper return 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-light-fix-improper-return-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 Tue Nov 28 10:49:28 CET 2017 From: Pan Bian <bianpan2016(a)163.com> Date: Sat, 3 Dec 2016 17:24:17 +0800 Subject: iio: light: fix improper return value From: Pan Bian <bianpan2016(a)163.com> [ Upstream commit db4e5376d058af8924fafd0520a0942d92538d0e ] In function cm3232_reg_init(), it returns 0 even if the last call to i2c_smbus_write_byte_data() returns a negative value (indicates error). As a result, the return value may be inconsistent with the execution status, and the caller of cm3232_reg_init() will not be able to detect the error. This patch fixes the bug. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=188641 Signed-off-by: Pan Bian <bianpan2016(a)163.com> Signed-off-by: Jonathan Cameron <jic23(a)kernel.org> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/iio/light/cm3232.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/iio/light/cm3232.c +++ b/drivers/iio/light/cm3232.c @@ -119,7 +119,7 @@ static int cm3232_reg_init(struct cm3232 if (ret < 0) dev_err(&chip->client->dev, "Error writing reg_cmd\n"); - return 0; + return ret; } /** Patches currently in stable-queue which might be from bianpan2016(a)163.com are queue-4.9/iio-light-fix-improper-return-value.patch queue-4.9/net-3com-typhoon-typhoon_init_one-fix-incorrect-return-values.patch queue-4.9/btrfs-return-the-actual-error-value-from-from-btrfs_uuid_tree_iterate.patch queue-4.9/staging-iio-cdc-fix-improper-return-value.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "gpio: mockup: dynamically allocate memory for chip name" 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 gpio: mockup: dynamically allocate memory for chip name 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: gpio-mockup-dynamically-allocate-memory-for-chip-name.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 Tue Nov 28 10:49:28 CET 2017 From: Bartosz Golaszewski <bgolaszewski(a)baylibre.com> Date: Tue, 20 Dec 2016 12:28:19 +0100 Subject: gpio: mockup: dynamically allocate memory for chip name From: Bartosz Golaszewski <bgolaszewski(a)baylibre.com> [ Upstream commit ad6d8004fa29a8958381b60215e32d1e903b0492 ] Currently the chip name buffer is allocated on the stack and the address of the buffer is passed to the gpio framework. It's invalid after probe() returns, so the sysfs label attribute displays garbage. Use devm_kasprintf() for each string instead. Signed-off-by: Bartosz Golaszewski <bgolaszewski(a)baylibre.com> Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/gpio/gpio-mockup.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) --- a/drivers/gpio/gpio-mockup.c +++ b/drivers/gpio/gpio-mockup.c @@ -126,7 +126,7 @@ static int mockup_gpio_probe(struct plat int i; int base; int ngpio; - char chip_name[sizeof(GPIO_NAME) + 3]; + char *chip_name; if (gpio_mockup_params_nr < 2) return -EINVAL; @@ -146,8 +146,12 @@ static int mockup_gpio_probe(struct plat ngpio = gpio_mockup_ranges[i * 2 + 1] - base; if (ngpio >= 0) { - sprintf(chip_name, "%s-%c", GPIO_NAME, - pins_name_start + i); + chip_name = devm_kasprintf(dev, GFP_KERNEL, + "%s-%c", GPIO_NAME, + pins_name_start + i); + if (!chip_name) + return -ENOMEM; + ret = mockup_gpio_add(dev, &cntr[i], chip_name, base, ngpio); } else { Patches currently in stable-queue which might be from bgolaszewski(a)baylibre.com are queue-4.9/gpio-mockup-dynamically-allocate-memory-for-chip-name.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "fscrypt: use ENOTDIR when setting encryption policy on nondirectory" 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 fscrypt: use ENOTDIR when setting encryption policy on nondirectory 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: fscrypt-use-enotdir-when-setting-encryption-policy-on-nondirectory.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 Tue Nov 28 10:49:28 CET 2017 From: Eric Biggers <ebiggers(a)google.com> Date: Mon, 5 Dec 2016 11:12:45 -0800 Subject: fscrypt: use ENOTDIR when setting encryption policy on nondirectory From: Eric Biggers <ebiggers(a)google.com> [ Upstream commit dffd0cfa06d4ed83bb3ae8eb067989ceec5d18e1 ] As part of an effort to clean up fscrypt-related error codes, make FS_IOC_SET_ENCRYPTION_POLICY fail with ENOTDIR when the file descriptor does not refer to a directory. This is more descriptive than EINVAL, which was ambiguous with some of the other error cases. I am not aware of any users who might be relying on the previous error code of EINVAL, which was never documented anywhere, and in some buggy kernels did not exist at all as the S_ISDIR() check was missing. This failure case will be exercised by an xfstest. Signed-off-by: Eric Biggers <ebiggers(a)google.com> Signed-off-by: Theodore Ts'o <tytso(a)mit.edu> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/crypto/policy.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/fs/crypto/policy.c +++ b/fs/crypto/policy.c @@ -113,7 +113,7 @@ int fscrypt_process_policy(struct file * if (!inode_has_encryption_context(inode)) { if (!S_ISDIR(inode->i_mode)) - ret = -EINVAL; + ret = -ENOTDIR; else if (!inode->i_sb->s_cop->empty_dir) ret = -EOPNOTSUPP; else if (!inode->i_sb->s_cop->empty_dir(inode)) Patches currently in stable-queue which might be from ebiggers(a)google.com are queue-4.9/fscrypt-use-enotdir-when-setting-encryption-policy-on-nondirectory.patch queue-4.9/lib-mpi-call-cond_resched-from-mpi_powm-loop.patch queue-4.9/fscrypt-use-enokey-when-file-cannot-be-created-w-o-key.patch queue-4.9/fscrypt-lock-mutex-before-checking-for-bounce-page-pool.patch queue-4.9/dm-bufio-fix-integer-overflow-when-limiting-maximum-cache-size.patch queue-4.9/libceph-don-t-warn-if-user-tries-to-add-invalid-key.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "fscrypt: use ENOKEY when file cannot be created w/o key" 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 fscrypt: use ENOKEY when file cannot be created w/o key 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: fscrypt-use-enokey-when-file-cannot-be-created-w-o-key.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 Tue Nov 28 10:49:28 CET 2017 From: Eric Biggers <ebiggers(a)google.com> Date: Mon, 5 Dec 2016 11:12:44 -0800 Subject: fscrypt: use ENOKEY when file cannot be created w/o key From: Eric Biggers <ebiggers(a)google.com> [ Upstream commit 54475f531bb8d7078f63c159e5e0615d486c498c ] As part of an effort to clean up fscrypt-related error codes, make attempting to create a file in an encrypted directory that hasn't been "unlocked" fail with ENOKEY. Previously, several error codes were used for this case, including ENOENT, EACCES, and EPERM, and they were not consistent between and within filesystems. ENOKEY is a better choice because it expresses that the failure is due to lacking the encryption key. It also matches the error code returned when trying to open an encrypted regular file without the key. I am not aware of any users who might be relying on the previous inconsistent error codes, which were never documented anywhere. This failure case will be exercised by an xfstest. Signed-off-by: Eric Biggers <ebiggers(a)google.com> Signed-off-by: Theodore Ts'o <tytso(a)mit.edu> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/crypto/fname.c | 4 ++-- fs/ext4/ialloc.c | 2 +- fs/ext4/namei.c | 4 +++- fs/f2fs/dir.c | 5 ++++- fs/f2fs/namei.c | 4 ++-- 5 files changed, 12 insertions(+), 7 deletions(-) --- a/fs/crypto/fname.c +++ b/fs/crypto/fname.c @@ -332,7 +332,7 @@ int fscrypt_fname_usr_to_disk(struct ino * in a directory. Consequently, a user space name cannot be mapped to * a disk-space name */ - return -EACCES; + return -ENOKEY; } EXPORT_SYMBOL(fscrypt_fname_usr_to_disk); @@ -367,7 +367,7 @@ int fscrypt_setup_filename(struct inode return 0; } if (!lookup) - return -EACCES; + return -ENOKEY; /* * We don't have the key and we are doing a lookup; decode the --- a/fs/ext4/ialloc.c +++ b/fs/ext4/ialloc.c @@ -771,7 +771,7 @@ struct inode *__ext4_new_inode(handle_t if (err) return ERR_PTR(err); if (!fscrypt_has_encryption_key(dir)) - return ERR_PTR(-EPERM); + return ERR_PTR(-ENOKEY); if (!handle) nblocks += EXT4_DATA_TRANS_BLOCKS(dir->i_sb); encrypt = 1; --- a/fs/ext4/namei.c +++ b/fs/ext4/namei.c @@ -1378,6 +1378,8 @@ static struct buffer_head * ext4_find_en return NULL; retval = ext4_fname_setup_filename(dir, d_name, 1, &fname); + if (retval == -ENOENT) + return NULL; if (retval) return ERR_PTR(retval); @@ -3090,7 +3092,7 @@ static int ext4_symlink(struct inode *di if (err) return err; if (!fscrypt_has_encryption_key(dir)) - return -EPERM; + return -ENOKEY; disk_link.len = (fscrypt_fname_encrypted_size(dir, len) + sizeof(struct fscrypt_symlink_data)); sd = kzalloc(disk_link.len, GFP_KERNEL); --- a/fs/f2fs/dir.c +++ b/fs/f2fs/dir.c @@ -277,7 +277,10 @@ struct f2fs_dir_entry *f2fs_find_entry(s err = fscrypt_setup_filename(dir, child, 1, &fname); if (err) { - *res_page = ERR_PTR(err); + if (err == -ENOENT) + *res_page = NULL; + else + *res_page = ERR_PTR(err); return NULL; } --- a/fs/f2fs/namei.c +++ b/fs/f2fs/namei.c @@ -403,7 +403,7 @@ static int f2fs_symlink(struct inode *di return err; if (!fscrypt_has_encryption_key(dir)) - return -EPERM; + return -ENOKEY; disk_link.len = (fscrypt_fname_encrypted_size(dir, len) + sizeof(struct fscrypt_symlink_data)); @@ -447,7 +447,7 @@ static int f2fs_symlink(struct inode *di goto err_out; if (!fscrypt_has_encryption_key(inode)) { - err = -EPERM; + err = -ENOKEY; goto err_out; } Patches currently in stable-queue which might be from ebiggers(a)google.com are queue-4.9/fscrypt-use-enotdir-when-setting-encryption-policy-on-nondirectory.patch queue-4.9/lib-mpi-call-cond_resched-from-mpi_powm-loop.patch queue-4.9/fscrypt-use-enokey-when-file-cannot-be-created-w-o-key.patch queue-4.9/fscrypt-lock-mutex-before-checking-for-bounce-page-pool.patch queue-4.9/dm-bufio-fix-integer-overflow-when-limiting-maximum-cache-size.patch queue-4.9/libceph-don-t-warn-if-user-tries-to-add-invalid-key.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "drm/sun4i: Fix a return value in case of error" 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 drm/sun4i: Fix a return value in case of error 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: drm-sun4i-fix-a-return-value-in-case-of-error.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 Tue Nov 28 10:49:28 CET 2017 From: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr> Date: Fri, 18 Nov 2016 19:18:47 +0100 Subject: drm/sun4i: Fix a return value in case of error From: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr> [ Upstream commit 0f0861e31e3c59ca4bc1ec59d99260cfca79740e ] If 'sun4i_backend_drm_format_to_layer()' does not return 0, then 'val' is left unmodified. As it is not initialized either, the return value can be anything. It is likely that returning the error code was expected here. As the only caller of 'sun4i_backend_update_layer_formats()' does not check the return value, this fix is purely theorical. Signed-off-by: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr> Signed-off-by: Maxime Ripard <maxime.ripard(a)free-electrons.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/gpu/drm/sun4i/sun4i_backend.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/gpu/drm/sun4i/sun4i_backend.c +++ b/drivers/gpu/drm/sun4i/sun4i_backend.c @@ -172,7 +172,7 @@ int sun4i_backend_update_layer_formats(s ret = sun4i_backend_drm_format_to_layer(plane, fb->pixel_format, &val); if (ret) { DRM_DEBUG_DRIVER("Invalid format\n"); - return val; + return ret; } regmap_update_bits(backend->regs, SUN4I_BACKEND_ATTCTL_REG1(layer), Patches currently in stable-queue which might be from christophe.jaillet(a)wanadoo.fr are queue-4.9/drm-sun4i-fix-a-return-value-in-case-of-error.patch queue-4.9/pinctrl-sirf-atlas7-add-missing-of_node_put.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "drm/mediatek: don't use drm_put_dev" 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 drm/mediatek: don't use drm_put_dev 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: drm-mediatek-don-t-use-drm_put_dev.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 Tue Nov 28 10:49:28 CET 2017 From: Daniel Vetter <daniel.vetter(a)ffwll.ch> Date: Thu, 8 Dec 2016 12:07:38 +0100 Subject: drm/mediatek: don't use drm_put_dev From: Daniel Vetter <daniel.vetter(a)ffwll.ch> [ Upstream commit ae9d2daecf086958a41ad216152ec208d70ba325 ] fsl is already fully demidlayered in the probe function, but for convenience stuck with drm_put_dev. Call the unregister/unref parts separately, to make sure this driver works correct. Cc: Philipp Zabel <p.zabel(a)pengutronix.de> Cc: CK Hu <ck.hu(a)mediatek.com> Reviewed-by: Lucas Stach <l.stach(a)pengutronix.de> Signed-off-by: Daniel Vetter <daniel.vetter(a)intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161208110739.24417-3-daniel.… Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/gpu/drm/mediatek/mtk_drm_drv.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c @@ -321,7 +321,8 @@ static void mtk_drm_unbind(struct device { struct mtk_drm_private *private = dev_get_drvdata(dev); - drm_put_dev(private->drm); + drm_dev_unregister(private->drm); + drm_dev_unref(private->drm); private->drm = NULL; } Patches currently in stable-queue which might be from daniel.vetter(a)ffwll.ch are queue-4.9/drm-mediatek-don-t-use-drm_put_dev.patch queue-4.9/drm-armada-fix-compile-fail.patch queue-4.9/drm-apply-range-restriction-after-color-adjustment-when-allocation.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "drm/armada: Fix compile fail" 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 drm/armada: Fix compile fail 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: drm-armada-fix-compile-fail.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 Tue Nov 28 10:49:28 CET 2017 From: Daniel Vetter <daniel.vetter(a)ffwll.ch> Date: Fri, 30 Dec 2016 17:38:52 +0100 Subject: drm/armada: Fix compile fail From: Daniel Vetter <daniel.vetter(a)ffwll.ch> [ Upstream commit 7357f89954b6d005df6ab8929759e78d7d9a80f9 ] I reported the include issue for tracepoints a while ago, but nothing seems to have happened. Now it bit us, since the drm_mm_print conversion was broken for armada. Fix it, so I can re-enable armada in the drm-misc build configs. v2: Rebase just the compile fix on top of Chris' build fix. Cc: Russell King <rmk+kernel(a)armlinux.org.uk> Cc: Chris Wilson <chris(a)chris-wilson.co.uk> Acked: Chris Wilson <chris(a)chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter(a)intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1483115932-19584-1-git-send-em… Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/gpu/drm/armada/Makefile | 2 ++ 1 file changed, 2 insertions(+) --- a/drivers/gpu/drm/armada/Makefile +++ b/drivers/gpu/drm/armada/Makefile @@ -4,3 +4,5 @@ armada-y += armada_510.o armada-$(CONFIG_DEBUG_FS) += armada_debugfs.o obj-$(CONFIG_DRM_ARMADA) := armada.o + +CFLAGS_armada_trace.o := -I$(src) Patches currently in stable-queue which might be from daniel.vetter(a)ffwll.ch are queue-4.9/drm-mediatek-don-t-use-drm_put_dev.patch queue-4.9/drm-armada-fix-compile-fail.patch queue-4.9/drm-apply-range-restriction-after-color-adjustment-when-allocation.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "drm: Apply range restriction after color adjustment when allocation" 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 drm: Apply range restriction after color adjustment when allocation 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: drm-apply-range-restriction-after-color-adjustment-when-allocation.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 Tue Nov 28 10:49:28 CET 2017 From: Chris Wilson <chris(a)chris-wilson.co.uk> Date: Thu, 22 Dec 2016 08:36:38 +0000 Subject: drm: Apply range restriction after color adjustment when allocation From: Chris Wilson <chris(a)chris-wilson.co.uk> [ Upstream commit 3db93756b501e5f0a3951c79cfa9ed43c26d3455 ] mm->color_adjust() compares the hole with its neighbouring nodes. They only abutt before we restrict the hole, so we have to apply color_adjust before we apply the range restriction. Signed-off-by: Chris Wilson <chris(a)chris-wilson.co.uk> Reviewed-by: Joonas Lahtinen <joonas.lahtinen(a)linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter(a)ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20161222083641.2691-36-chris@c… Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/gpu/drm/drm_mm.c | 16 ++++++---------- 1 file changed, 6 insertions(+), 10 deletions(-) --- a/drivers/gpu/drm/drm_mm.c +++ b/drivers/gpu/drm/drm_mm.c @@ -348,14 +348,12 @@ static void drm_mm_insert_helper_range(s BUG_ON(!hole_node->hole_follows || node->allocated); - if (adj_start < start) - adj_start = start; - if (adj_end > end) - adj_end = end; - if (mm->color_adjust) mm->color_adjust(hole_node, color, &adj_start, &adj_end); + adj_start = max(adj_start, start); + adj_end = min(adj_end, end); + if (flags & DRM_MM_CREATE_TOP) adj_start = adj_end - size; @@ -566,17 +564,15 @@ static struct drm_mm_node *drm_mm_search flags & DRM_MM_SEARCH_BELOW) { u64 hole_size = adj_end - adj_start; - if (adj_start < start) - adj_start = start; - if (adj_end > end) - adj_end = end; - if (mm->color_adjust) { mm->color_adjust(entry, color, &adj_start, &adj_end); if (adj_end <= adj_start) continue; } + adj_start = max(adj_start, start); + adj_end = min(adj_end, end); + if (!check_free_hole(adj_start, adj_end, size, alignment)) continue; Patches currently in stable-queue which might be from chris(a)chris-wilson.co.uk are queue-4.9/drm-armada-fix-compile-fail.patch queue-4.9/drm-apply-range-restriction-after-color-adjustment-when-allocation.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "dmaengine: zx: set DMA_CYCLIC cap_mask bit" 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 dmaengine: zx: set DMA_CYCLIC cap_mask bit 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: dmaengine-zx-set-dma_cyclic-cap_mask-bit.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 Tue Nov 28 10:49:28 CET 2017 From: Shawn Guo <shawn.guo(a)linaro.org> Date: Thu, 15 Dec 2016 22:03:36 +0800 Subject: dmaengine: zx: set DMA_CYCLIC cap_mask bit From: Shawn Guo <shawn.guo(a)linaro.org> [ Upstream commit fc318d64f3d91e15babac00e08354b1beb650b57 ] The zx_dma driver supports cyclic transfer mode. Let's set DMA_CYCLIC cap_mask bit to make that clear, and avoid unnecessary failure when clients request channel via dma_request_chan_by_mask() with DMA_CYCLIC bit set in mask. Signed-off-by: Shawn Guo <shawn.guo(a)linaro.org> Reviewed-by: Jun Nie <jun.nie(a)linaro.org> Signed-off-by: Vinod Koul <vinod.koul(a)intel.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/dma/zx296702_dma.c | 1 + 1 file changed, 1 insertion(+) --- a/drivers/dma/zx296702_dma.c +++ b/drivers/dma/zx296702_dma.c @@ -813,6 +813,7 @@ static int zx_dma_probe(struct platform_ INIT_LIST_HEAD(&d->slave.channels); dma_cap_set(DMA_SLAVE, d->slave.cap_mask); dma_cap_set(DMA_MEMCPY, d->slave.cap_mask); + dma_cap_set(DMA_CYCLIC, d->slave.cap_mask); dma_cap_set(DMA_PRIVATE, d->slave.cap_mask); d->slave.dev = &op->dev; d->slave.device_free_chan_resources = zx_dma_free_chan_resources; Patches currently in stable-queue which might be from shawn.guo(a)linaro.org are queue-4.9/dmaengine-zx-set-dma_cyclic-cap_mask-bit.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "crypto: marvell - Copy IVDIG before launching partial DMA ahash requests" 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 crypto: marvell - Copy IVDIG before launching partial DMA ahash requests 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: crypto-marvell-copy-ivdig-before-launching-partial-dma-ahash-requests.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 Tue Nov 28 10:49:28 CET 2017 From: Romain Perier <romain.perier(a)free-electrons.com> Date: Wed, 14 Dec 2016 15:15:07 +0100 Subject: crypto: marvell - Copy IVDIG before launching partial DMA ahash requests From: Romain Perier <romain.perier(a)free-electrons.com> [ Upstream commit 8759fec4af222f338d08f8f1a7ad6a77ca6cb301 ] Currently, inner IV/DIGEST data are only copied once into the hash engines and not set explicitly before launching a request that is not a first frag. This is an issue especially when multiple ahash reqs are computed in parallel or chained with cipher request, as the state of the request being computed is not updated into the hash engine. It leads to non-deterministic corrupted digest results. Fixes: commit 2786cee8e50b ("crypto: marvell - Move SRAM I/O operations to step functions") Signed-off-by: Romain Perier <romain.perier(a)free-electrons.com> Acked-by: Boris Brezillon <boris.brezillon(a)free-electrons.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/crypto/marvell/cesa.h | 3 ++- drivers/crypto/marvell/hash.c | 34 +++++++++++++++++++++++++++++++++- drivers/crypto/marvell/tdma.c | 9 ++++++++- 3 files changed, 43 insertions(+), 3 deletions(-) --- a/drivers/crypto/marvell/cesa.h +++ b/drivers/crypto/marvell/cesa.h @@ -273,7 +273,8 @@ struct mv_cesa_op_ctx { #define CESA_TDMA_SRC_IN_SRAM BIT(30) #define CESA_TDMA_END_OF_REQ BIT(29) #define CESA_TDMA_BREAK_CHAIN BIT(28) -#define CESA_TDMA_TYPE_MSK GENMASK(27, 0) +#define CESA_TDMA_SET_STATE BIT(27) +#define CESA_TDMA_TYPE_MSK GENMASK(26, 0) #define CESA_TDMA_DUMMY 0 #define CESA_TDMA_DATA 1 #define CESA_TDMA_OP 2 --- a/drivers/crypto/marvell/hash.c +++ b/drivers/crypto/marvell/hash.c @@ -280,13 +280,32 @@ static void mv_cesa_ahash_std_prepare(st sreq->offset = 0; } +static void mv_cesa_ahash_dma_step(struct ahash_request *req) +{ + struct mv_cesa_ahash_req *creq = ahash_request_ctx(req); + struct mv_cesa_req *base = &creq->base; + + /* We must explicitly set the digest state. */ + if (base->chain.first->flags & CESA_TDMA_SET_STATE) { + struct mv_cesa_engine *engine = base->engine; + int i; + + /* Set the hash state in the IVDIG regs. */ + for (i = 0; i < ARRAY_SIZE(creq->state); i++) + writel_relaxed(creq->state[i], engine->regs + + CESA_IVDIG(i)); + } + + mv_cesa_dma_step(base); +} + static void mv_cesa_ahash_step(struct crypto_async_request *req) { struct ahash_request *ahashreq = ahash_request_cast(req); struct mv_cesa_ahash_req *creq = ahash_request_ctx(ahashreq); if (mv_cesa_req_get_type(&creq->base) == CESA_DMA_REQ) - mv_cesa_dma_step(&creq->base); + mv_cesa_ahash_dma_step(ahashreq); else mv_cesa_ahash_std_step(ahashreq); } @@ -562,11 +581,15 @@ static int mv_cesa_ahash_dma_req_init(st struct mv_cesa_ahash_dma_iter iter; struct mv_cesa_op_ctx *op = NULL; unsigned int frag_len; + bool set_state = false; int ret; basereq->chain.first = NULL; basereq->chain.last = NULL; + if (!mv_cesa_mac_op_is_first_frag(&creq->op_tmpl)) + set_state = true; + if (creq->src_nents) { ret = dma_map_sg(cesa_dev->dev, req->src, creq->src_nents, DMA_TO_DEVICE); @@ -650,6 +673,15 @@ static int mv_cesa_ahash_dma_req_init(st basereq->chain.last->flags |= (CESA_TDMA_END_OF_REQ | CESA_TDMA_BREAK_CHAIN); + if (set_state) { + /* + * Put the CESA_TDMA_SET_STATE flag on the first tdma desc to + * let the step logic know that the IVDIG registers should be + * explicitly set before launching a TDMA chain. + */ + basereq->chain.first->flags |= CESA_TDMA_SET_STATE; + } + return 0; err_free_tdma: --- a/drivers/crypto/marvell/tdma.c +++ b/drivers/crypto/marvell/tdma.c @@ -112,7 +112,14 @@ void mv_cesa_tdma_chain(struct mv_cesa_e last->next = dreq->chain.first; engine->chain.last = dreq->chain.last; - if (!(last->flags & CESA_TDMA_BREAK_CHAIN)) + /* + * Break the DMA chain if the CESA_TDMA_BREAK_CHAIN is set on + * the last element of the current chain, or if the request + * being queued needs the IV regs to be set before lauching + * the request. + */ + if (!(last->flags & CESA_TDMA_BREAK_CHAIN) && + !(dreq->chain.first->flags & CESA_TDMA_SET_STATE)) last->next_dma = dreq->chain.first->cur_dma; } } Patches currently in stable-queue which might be from romain.perier(a)free-electrons.com are queue-4.9/crypto-marvell-copy-ivdig-before-launching-partial-dma-ahash-requests.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "clk: sunxi-ng: fix PLL_CPUX adjusting on A33" 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 clk: sunxi-ng: fix PLL_CPUX adjusting on A33 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: clk-sunxi-ng-fix-pll_cpux-adjusting-on-a33.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 Tue Nov 28 10:49:28 CET 2017 From: Icenowy Zheng <icenowy(a)aosc.xyz> Date: Tue, 13 Dec 2016 23:22:47 +0800 Subject: clk: sunxi-ng: fix PLL_CPUX adjusting on A33 From: Icenowy Zheng <icenowy(a)aosc.xyz> [ Upstream commit 790d929b540661945d1c70652ffb602c5c06ad85 ] When adjusting PLL_CPUX on A33, the PLL is temporarily driven too high, and the system hangs. Add a notifier to avoid this situation by temporarily switching to a known stable 24 MHz oscillator. Signed-off-by: Icenowy Zheng <icenowy(a)aosc.xyz> Signed-off-by: Maxime Ripard <maxime.ripard(a)free-electrons.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/clk/sunxi-ng/ccu-sun8i-a33.c | 10 ++++++++++ 1 file changed, 10 insertions(+) --- a/drivers/clk/sunxi-ng/ccu-sun8i-a33.c +++ b/drivers/clk/sunxi-ng/ccu-sun8i-a33.c @@ -752,6 +752,13 @@ static const struct sunxi_ccu_desc sun8i .num_resets = ARRAY_SIZE(sun8i_a33_ccu_resets), }; +static struct ccu_mux_nb sun8i_a33_cpu_nb = { + .common = &cpux_clk.common, + .cm = &cpux_clk.mux, + .delay_us = 1, /* > 8 clock cycles at 24 MHz */ + .bypass_index = 1, /* index of 24 MHz oscillator */ +}; + static void __init sun8i_a33_ccu_setup(struct device_node *node) { void __iomem *reg; @@ -775,6 +782,9 @@ static void __init sun8i_a33_ccu_setup(s writel(val, reg + SUN8I_A33_PLL_MIPI_REG); sunxi_ccu_probe(node, reg, &sun8i_a33_ccu_desc); + + ccu_mux_notifier_register(pll_cpux_clk.common.hw.clk, + &sun8i_a33_cpu_nb); } CLK_OF_DECLARE(sun8i_a33_ccu, "allwinner,sun8i-a33-ccu", sun8i_a33_ccu_setup); Patches currently in stable-queue which might be from icenowy(a)aosc.xyz are queue-4.9/clk-sunxi-ng-fix-pll_cpux-adjusting-on-a33.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "clk: sunxi-ng: A31: Fix spdif clock register" 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 clk: sunxi-ng: A31: Fix spdif clock register 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: clk-sunxi-ng-a31-fix-spdif-clock-register.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 Tue Nov 28 10:49:28 CET 2017 From: Marcus Cooper <codekipper(a)gmail.com> Date: Tue, 20 Dec 2016 11:44:46 +0100 Subject: clk: sunxi-ng: A31: Fix spdif clock register From: Marcus Cooper <codekipper(a)gmail.com> [ Upstream commit 70421257c068b91476e70cade15fca68045d0693 ] As the SPDIF was rarely documented on the earlier Allwinner SoCs it was assumed that it had a similar clock register to the one described in the H3 User Manual. However this is not the case and it looks to shares the same setup as the I2S clock registers. Signed-off-by: Marcus Cooper <codekipper(a)gmail.com> Signed-off-by: Maxime Ripard <maxime.ripard(a)free-electrons.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/clk/sunxi-ng/ccu-sun6i-a31.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/drivers/clk/sunxi-ng/ccu-sun6i-a31.c +++ b/drivers/clk/sunxi-ng/ccu-sun6i-a31.c @@ -468,8 +468,8 @@ static SUNXI_CCU_MUX_WITH_GATE(daudio0_c static SUNXI_CCU_MUX_WITH_GATE(daudio1_clk, "daudio1", daudio_parents, 0x0b4, 16, 2, BIT(31), CLK_SET_RATE_PARENT); -static SUNXI_CCU_M_WITH_GATE(spdif_clk, "spdif", "pll-audio", - 0x0c0, 0, 4, BIT(31), CLK_SET_RATE_PARENT); +static SUNXI_CCU_MUX_WITH_GATE(spdif_clk, "spdif", daudio_parents, + 0x0c0, 16, 2, BIT(31), CLK_SET_RATE_PARENT); static SUNXI_CCU_GATE(usb_phy0_clk, "usb-phy0", "osc24M", 0x0cc, BIT(8), 0); Patches currently in stable-queue which might be from codekipper(a)gmail.com are queue-4.9/clk-sunxi-ng-a31-fix-spdif-clock-register.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "clk: qcom: ipq4019: Add all the frequencies for apss cpu" 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 clk: qcom: ipq4019: Add all the frequencies for apss cpu 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: clk-qcom-ipq4019-add-all-the-frequencies-for-apss-cpu.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 Tue Nov 28 10:49:28 CET 2017 From: Abhishek Sahu <absahu(a)codeaurora.org> Date: Fri, 25 Nov 2016 21:11:32 +0530 Subject: clk: qcom: ipq4019: Add all the frequencies for apss cpu From: Abhishek Sahu <absahu(a)codeaurora.org> [ Upstream commit 86c654d41a52e3d17e9bc2c2ba37f3c963e66a4a ] The APSS CPU clock does not contain all the frequencies in its frequency table so this patch adds the same. Signed-off-by: Abhishek Sahu <absahu(a)codeaurora.org> Signed-off-by: Stephen Boyd <sboyd(a)codeaurora.org> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/clk/qcom/gcc-ipq4019.c | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) --- a/drivers/clk/qcom/gcc-ipq4019.c +++ b/drivers/clk/qcom/gcc-ipq4019.c @@ -525,10 +525,20 @@ static struct clk_rcg2 sdcc1_apps_clk_s }; static const struct freq_tbl ftbl_gcc_apps_clk[] = { - F(48000000, P_XO, 1, 0, 0), + F(48000000, P_XO, 1, 0, 0), F(200000000, P_FEPLL200, 1, 0, 0), + F(384000000, P_DDRPLLAPSS, 1, 0, 0), + F(413000000, P_DDRPLLAPSS, 1, 0, 0), + F(448000000, P_DDRPLLAPSS, 1, 0, 0), + F(488000000, P_DDRPLLAPSS, 1, 0, 0), F(500000000, P_FEPLL500, 1, 0, 0), - F(626000000, P_DDRPLLAPSS, 1, 0, 0), + F(512000000, P_DDRPLLAPSS, 1, 0, 0), + F(537000000, P_DDRPLLAPSS, 1, 0, 0), + F(565000000, P_DDRPLLAPSS, 1, 0, 0), + F(597000000, P_DDRPLLAPSS, 1, 0, 0), + F(632000000, P_DDRPLLAPSS, 1, 0, 0), + F(672000000, P_DDRPLLAPSS, 1, 0, 0), + F(716000000, P_DDRPLLAPSS, 1, 0, 0), { } }; Patches currently in stable-queue which might be from absahu(a)codeaurora.org are queue-4.9/clk-qcom-ipq4019-add-all-the-frequencies-for-apss-cpu.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "[media] cec: when canceling a message, don't overwrite old status info" 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 [media] cec: when canceling a message, don't overwrite old status info 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: cec-when-canceling-a-message-don-t-overwrite-old-status-info.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 Tue Nov 28 10:49:28 CET 2017 From: Hans Verkuil <hansverk(a)cisco.com> Date: Fri, 9 Dec 2016 11:14:32 -0200 Subject: [media] cec: when canceling a message, don't overwrite old status info From: Hans Verkuil <hansverk(a)cisco.com> [ Upstream commit 120476123646ba3619c90db7bcbc6f8eea53c990 ] When a pending message was canceled (e.g. due to a timeout), then the old tx_status info was overwritten instead of ORed. The same happened with the tx_error_cnt field. So just modify them instead of overwriting them. Signed-off-by: Hans Verkuil <hans.verkuil(a)cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/staging/media/cec/cec-adap.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) --- a/drivers/staging/media/cec/cec-adap.c +++ b/drivers/staging/media/cec/cec-adap.c @@ -288,10 +288,10 @@ static void cec_data_cancel(struct cec_d /* Mark it as an error */ data->msg.tx_ts = ktime_get_ns(); - data->msg.tx_status = CEC_TX_STATUS_ERROR | - CEC_TX_STATUS_MAX_RETRIES; + data->msg.tx_status |= CEC_TX_STATUS_ERROR | + CEC_TX_STATUS_MAX_RETRIES; + data->msg.tx_error_cnt++; data->attempts = 0; - data->msg.tx_error_cnt = 1; /* Queue transmitted message for monitoring purposes */ cec_queue_msg_monitor(data->adap, &data->msg, 1); Patches currently in stable-queue which might be from hansverk(a)cisco.com are queue-4.9/cec-cec_msg_give_features-should-abort-for-cec-version-2.patch queue-4.9/cec-update-log_addr-before-finishing-configuration.patch queue-4.9/cec-when-canceling-a-message-don-t-overwrite-old-status-info.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "[media] cec: update log_addr[] before finishing configuration" 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 [media] cec: update log_addr[] before finishing configuration 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: cec-update-log_addr-before-finishing-configuration.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 Tue Nov 28 10:49:28 CET 2017 From: Hans Verkuil <hansverk(a)cisco.com> Date: Fri, 9 Dec 2016 11:54:06 -0200 Subject: [media] cec: update log_addr[] before finishing configuration From: Hans Verkuil <hansverk(a)cisco.com> [ Upstream commit 7af26f889eb67db272021a939f7d4a57e96dd961 ] The loop that sets the unused logical addresses to INVALID should be done before 'configured' is set to true. This ensures that cec_log_addrs is consistent before it will be used. Signed-off-by: Hans Verkuil <hansverk(a)cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/staging/media/cec/cec-adap.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/drivers/staging/media/cec/cec-adap.c +++ b/drivers/staging/media/cec/cec-adap.c @@ -1062,6 +1062,8 @@ configured: for (i = 1; i < las->num_log_addrs; i++) las->log_addr[i] = CEC_LOG_ADDR_INVALID; } + for (i = las->num_log_addrs; i < CEC_MAX_LOG_ADDRS; i++) + las->log_addr[i] = CEC_LOG_ADDR_INVALID; adap->is_configured = true; adap->is_configuring = false; cec_post_state_event(adap); @@ -1079,8 +1081,6 @@ configured: cec_report_features(adap, i); cec_report_phys_addr(adap, i); } - for (i = las->num_log_addrs; i < CEC_MAX_LOG_ADDRS; i++) - las->log_addr[i] = CEC_LOG_ADDR_INVALID; mutex_lock(&adap->lock); adap->kthread_config = NULL; mutex_unlock(&adap->lock); Patches currently in stable-queue which might be from hansverk(a)cisco.com are queue-4.9/cec-cec_msg_give_features-should-abort-for-cec-version-2.patch queue-4.9/cec-update-log_addr-before-finishing-configuration.patch queue-4.9/cec-when-canceling-a-message-don-t-overwrite-old-status-info.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "[media] cec: CEC_MSG_GIVE_FEATURES should abort for CEC version < 2" 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 [media] cec: CEC_MSG_GIVE_FEATURES should abort for CEC version < 2 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: cec-cec_msg_give_features-should-abort-for-cec-version-2.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 Tue Nov 28 10:49:28 CET 2017 From: Hans Verkuil <hansverk(a)cisco.com> Date: Fri, 9 Dec 2016 11:28:19 -0200 Subject: [media] cec: CEC_MSG_GIVE_FEATURES should abort for CEC version < 2 From: Hans Verkuil <hansverk(a)cisco.com> [ Upstream commit a24f56d47930492c94ef6875bf45adf7607ca1a4 ] This is a 2.0 only message, so it should return Feature Abort if the adapter is configured for CEC version 1.4. Right now it does nothing, which means that the sender will time out. Signed-off-by: Hans Verkuil <hansverk(a)cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/staging/media/cec/cec-adap.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) --- a/drivers/staging/media/cec/cec-adap.c +++ b/drivers/staging/media/cec/cec-adap.c @@ -1557,9 +1557,9 @@ static int cec_receive_notify(struct cec } case CEC_MSG_GIVE_FEATURES: - if (adap->log_addrs.cec_version >= CEC_OP_CEC_VERSION_2_0) - return cec_report_features(adap, la_idx); - return 0; + if (adap->log_addrs.cec_version < CEC_OP_CEC_VERSION_2_0) + return cec_feature_abort(adap, msg); + return cec_report_features(adap, la_idx); default: /* Patches currently in stable-queue which might be from hansverk(a)cisco.com are queue-4.9/cec-cec_msg_give_features-should-abort-for-cec-version-2.patch queue-4.9/cec-update-log_addr-before-finishing-configuration.patch queue-4.9/cec-when-canceling-a-message-don-t-overwrite-old-status-info.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "btrfs: return the actual error value from from btrfs_uuid_tree_iterate" 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 btrfs: return the actual error value from from btrfs_uuid_tree_iterate 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: btrfs-return-the-actual-error-value-from-from-btrfs_uuid_tree_iterate.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 Tue Nov 28 10:49:28 CET 2017 From: Pan Bian <bianpan2016(a)163.com> Date: Sun, 4 Dec 2016 12:51:53 +0800 Subject: btrfs: return the actual error value from from btrfs_uuid_tree_iterate From: Pan Bian <bianpan2016(a)163.com> [ Upstream commit 73ba39ab9307340dc98ec3622891314bbc09cc2e ] In function btrfs_uuid_tree_iterate(), errno is assigned to variable ret on errors. However, it directly returns 0. It may be better to return ret. This patch also removes the warning, because the caller already prints a warning. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=188731 Signed-off-by: Pan Bian <bianpan2016(a)163.com> Reviewed-by: Omar Sandoval <osandov(a)fb.com> [ edited subject ] Signed-off-by: David Sterba <dsterba(a)suse.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/btrfs/uuid-tree.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) --- a/fs/btrfs/uuid-tree.c +++ b/fs/btrfs/uuid-tree.c @@ -351,7 +351,5 @@ skip: out: btrfs_free_path(path); - if (ret) - btrfs_warn(fs_info, "btrfs_uuid_tree_iterate failed %d", ret); - return 0; + return ret; } Patches currently in stable-queue which might be from bianpan2016(a)163.com are queue-4.9/iio-light-fix-improper-return-value.patch queue-4.9/net-3com-typhoon-typhoon_init_one-fix-incorrect-return-values.patch queue-4.9/btrfs-return-the-actual-error-value-from-from-btrfs_uuid_tree_iterate.patch queue-4.9/staging-iio-cdc-fix-improper-return-value.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "bnxt_en: Set default completion ring for async events." 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 bnxt_en: Set default completion ring for async events. 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: bnxt_en-set-default-completion-ring-for-async-events.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 Tue Nov 28 10:49:28 CET 2017 From: Michael Chan <michael.chan(a)broadcom.com> Date: Thu, 29 Dec 2016 12:13:42 -0500 Subject: bnxt_en: Set default completion ring for async events. From: Michael Chan <michael.chan(a)broadcom.com> [ Upstream commit 486b5c22ea1d35e00e90dd79a32a9ee530b18915 ] With the added support for the bnxt_re RDMA driver, both drivers can be allocating completion rings in any order. The firmware does not know which completion ring should be receiving async events. Add an extra step to tell firmware the completion ring number for receiving async events after bnxt_en allocates the completion rings. Signed-off-by: Michael Chan <michael.chan(a)broadcom.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/broadcom/bnxt/bnxt.c | 30 ++++++++++++++++++++++++++++++ 1 file changed, 30 insertions(+) --- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c +++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c @@ -3800,6 +3800,30 @@ static int hwrm_ring_alloc_send_msg(stru return rc; } +static int bnxt_hwrm_set_async_event_cr(struct bnxt *bp, int idx) +{ + int rc; + + if (BNXT_PF(bp)) { + struct hwrm_func_cfg_input req = {0}; + + bnxt_hwrm_cmd_hdr_init(bp, &req, HWRM_FUNC_CFG, -1, -1); + req.fid = cpu_to_le16(0xffff); + req.enables = cpu_to_le32(FUNC_CFG_REQ_ENABLES_ASYNC_EVENT_CR); + req.async_event_cr = cpu_to_le16(idx); + rc = hwrm_send_message(bp, &req, sizeof(req), HWRM_CMD_TIMEOUT); + } else { + struct hwrm_func_vf_cfg_input req = {0}; + + bnxt_hwrm_cmd_hdr_init(bp, &req, HWRM_FUNC_VF_CFG, -1, -1); + req.enables = + cpu_to_le32(FUNC_VF_CFG_REQ_ENABLES_ASYNC_EVENT_CR); + req.async_event_cr = cpu_to_le16(idx); + rc = hwrm_send_message(bp, &req, sizeof(req), HWRM_CMD_TIMEOUT); + } + return rc; +} + static int bnxt_hwrm_ring_alloc(struct bnxt *bp) { int i, rc = 0; @@ -3816,6 +3840,12 @@ static int bnxt_hwrm_ring_alloc(struct b goto err_out; BNXT_CP_DB(cpr->cp_doorbell, cpr->cp_raw_cons); bp->grp_info[i].cp_fw_ring_id = ring->fw_ring_id; + + if (!i) { + rc = bnxt_hwrm_set_async_event_cr(bp, ring->fw_ring_id); + if (rc) + netdev_warn(bp->dev, "Failed to set async event completion ring.\n"); + } } for (i = 0; i < bp->tx_nr_rings; i++) { Patches currently in stable-queue which might be from michael.chan(a)broadcom.com are queue-4.9/bnxt_en-set-default-completion-ring-for-async-events.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "ath10k: set CTS protection VDEV param only if VDEV is up" 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 ath10k: set CTS protection VDEV param only if VDEV is up 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: ath10k-set-cts-protection-vdev-param-only-if-vdev-is-up.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 Tue Nov 28 10:49:28 CET 2017 From: Bartosz Markowski <bartosz.markowski(a)tieto.com> Date: Thu, 15 Dec 2016 11:23:24 +0200 Subject: ath10k: set CTS protection VDEV param only if VDEV is up From: Bartosz Markowski <bartosz.markowski(a)tieto.com> [ Upstream commit 7cfe0455ee1218add152e986b89b4bb8dbeafcdd ] The cts protection vdev parameter, in new QCA9377 TF2.0 firmware, requires bss peer to be created for the STATION vdev type. bss peer is being allocated by the firmware after vdev_start/_up commands. mac80211 may call the cts protection setup at any time, so the we needs to track the situation and defer the cts configuration to prevent firmware asserts, like below: [00]: 0x05020001 0x000015B3 0x0099ACE2 0x00955B31 [04]: 0x0099ACE2 0x00060730 0x00000004 0x00000000 [08]: 0x0044C754 0x00412C10 0x00000000 0x00409C54 [12]: 0x00000009 0x00000000 0x00952F6C 0x00952F77 [16]: 0x00952CC4 0x00910712 0x00000000 0x00000000 [20]: 0x4099ACE2 0x0040E858 0x00421254 0x004127F4 [24]: 0x8099B9B2 0x0040E8B8 0x00000000 0xC099ACE2 [28]: 0x800B75CB 0x0040E8F8 0x00000007 0x00005008 [32]: 0x809B048A 0x0040E958 0x00000010 0x00433B10 [36]: 0x809AFBBC 0x0040E9A8 0x0042BB74 0x0042BBBC [40]: 0x8091D252 0x0040E9C8 0x0042BBBC 0x00000001 [44]: 0x809FFA45 0x0040EA78 0x0043D3E4 0x0042C2C8 [48]: 0x809FCEF4 0x0040EA98 0x0043D3E4 0x00000001 [52]: 0x80911210 0x0040EAE8 0x00000010 0x004041D0 [56]: 0x80911154 0x0040EB28 0x00400000 0x00000000 Signed-off-by: Bartosz Markowski <bartosz.markowski(a)tieto.com> Signed-off-by: Kalle Valo <kvalo(a)qca.qualcomm.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/wireless/ath/ath10k/mac.c | 51 ++++++++++++++++++++++++++++------ 1 file changed, 43 insertions(+), 8 deletions(-) --- a/drivers/net/wireless/ath/ath10k/mac.c +++ b/drivers/net/wireless/ath/ath10k/mac.c @@ -1224,6 +1224,36 @@ static int ath10k_monitor_recalc(struct return ath10k_monitor_stop(ar); } +static bool ath10k_mac_can_set_cts_prot(struct ath10k_vif *arvif) +{ + struct ath10k *ar = arvif->ar; + + lockdep_assert_held(&ar->conf_mutex); + + if (!arvif->is_started) { + ath10k_dbg(ar, ATH10K_DBG_MAC, "defer cts setup, vdev is not ready yet\n"); + return false; + } + + return true; +} + +static int ath10k_mac_set_cts_prot(struct ath10k_vif *arvif) +{ + struct ath10k *ar = arvif->ar; + u32 vdev_param; + + lockdep_assert_held(&ar->conf_mutex); + + vdev_param = ar->wmi.vdev_param->protection_mode; + + ath10k_dbg(ar, ATH10K_DBG_MAC, "mac vdev %d cts_protection %d\n", + arvif->vdev_id, arvif->use_cts_prot); + + return ath10k_wmi_vdev_set_param(ar, arvif->vdev_id, vdev_param, + arvif->use_cts_prot ? 1 : 0); +} + static int ath10k_recalc_rtscts_prot(struct ath10k_vif *arvif) { struct ath10k *ar = arvif->ar; @@ -5322,20 +5352,18 @@ static void ath10k_bss_info_changed(stru if (changed & BSS_CHANGED_ERP_CTS_PROT) { arvif->use_cts_prot = info->use_cts_prot; - ath10k_dbg(ar, ATH10K_DBG_MAC, "mac vdev %d cts_prot %d\n", - arvif->vdev_id, info->use_cts_prot); ret = ath10k_recalc_rtscts_prot(arvif); if (ret) ath10k_warn(ar, "failed to recalculate rts/cts prot for vdev %d: %d\n", arvif->vdev_id, ret); - vdev_param = ar->wmi.vdev_param->protection_mode; - ret = ath10k_wmi_vdev_set_param(ar, arvif->vdev_id, vdev_param, - info->use_cts_prot ? 1 : 0); - if (ret) - ath10k_warn(ar, "failed to set protection mode %d on vdev %i: %d\n", - info->use_cts_prot, arvif->vdev_id, ret); + if (ath10k_mac_can_set_cts_prot(arvif)) { + ret = ath10k_mac_set_cts_prot(arvif); + if (ret) + ath10k_warn(ar, "failed to set cts protection for vdev %d: %d\n", + arvif->vdev_id, ret); + } } if (changed & BSS_CHANGED_ERP_SLOT) { @@ -7356,6 +7384,13 @@ ath10k_mac_op_assign_vif_chanctx(struct arvif->is_up = true; } + if (ath10k_mac_can_set_cts_prot(arvif)) { + ret = ath10k_mac_set_cts_prot(arvif); + if (ret) + ath10k_warn(ar, "failed to set cts protection for vdev %d: %d\n", + arvif->vdev_id, ret); + } + mutex_unlock(&ar->conf_mutex); return 0; Patches currently in stable-queue which might be from bartosz.markowski(a)tieto.com are queue-4.9/ath10k-set-cts-protection-vdev-param-only-if-vdev-is-up.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "ath10k: ignore configuring the incorrect board_id" 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 ath10k: ignore configuring the incorrect board_id 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: ath10k-ignore-configuring-the-incorrect-board_id.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 Tue Nov 28 10:49:28 CET 2017 From: Ryan Hsu <ryanhsu(a)qca.qualcomm.com> Date: Thu, 22 Dec 2016 15:02:37 -0800 Subject: ath10k: ignore configuring the incorrect board_id From: Ryan Hsu <ryanhsu(a)qca.qualcomm.com> [ Upstream commit d2e202c06ca42d353d95df12437740921a6d05b5 ] With command to get board_id from otp, in the case of following boot get otp board id result 0x00000000 board_id 0 chip_id 0 boot using board name 'bus=pci,bmi-chip-id=0,bmi-board-id=0" ... failed to fetch board data for bus=pci,bmi-chip-id=0,bmi-board-id=0 from ath10k/QCA6174/hw3.0/board-2.bin The invalid board_id=0 will be used as index to search in the board-2.bin. Ignore the case with board_id=0, as it means the otp is not carrying the board id information. Signed-off-by: Ryan Hsu <ryanhsu(a)qca.qualcomm.com> Signed-off-by: Kalle Valo <kvalo(a)qca.qualcomm.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/wireless/ath/ath10k/core.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) --- a/drivers/net/wireless/ath/ath10k/core.c +++ b/drivers/net/wireless/ath/ath10k/core.c @@ -691,8 +691,11 @@ static int ath10k_core_get_board_id_from "boot get otp board id result 0x%08x board_id %d chip_id %d\n", result, board_id, chip_id); - if ((result & ATH10K_BMI_BOARD_ID_STATUS_MASK) != 0) + if ((result & ATH10K_BMI_BOARD_ID_STATUS_MASK) != 0 || + (board_id == 0)) { + ath10k_warn(ar, "board id is not exist in otp, ignore it\n"); return -EOPNOTSUPP; + } ar->id.bmi_ids_valid = true; ar->id.bmi_board_id = board_id; Patches currently in stable-queue which might be from ryanhsu(a)qca.qualcomm.com are queue-4.9/ath10k-fix-incorrect-txpower-set-by-p2p_device-interface.patch queue-4.9/ath10k-ignore-configuring-the-incorrect-board_id.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "ath10k: fix potential memory leak in ath10k_wmi_tlv_op_pull_fw_stats()" 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 ath10k: fix potential memory leak in ath10k_wmi_tlv_op_pull_fw_stats() 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: ath10k-fix-potential-memory-leak-in-ath10k_wmi_tlv_op_pull_fw_stats.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 Tue Nov 28 10:49:28 CET 2017 From: Christian Lamparter <chunkeey(a)googlemail.com> Date: Thu, 29 Dec 2016 16:12:09 +0200 Subject: ath10k: fix potential memory leak in ath10k_wmi_tlv_op_pull_fw_stats() From: Christian Lamparter <chunkeey(a)googlemail.com> [ Upstream commit 097e46d2ae90265d1afe141ba6208ba598b79e01 ] ath10k_wmi_tlv_op_pull_fw_stats() uses tb = ath10k_wmi_tlv_parse_alloc(...) function, which allocates memory. If any of the three error-paths are taken, this tb needs to be freed. Signed-off-by: Christian Lamparter <chunkeey(a)googlemail.com> Signed-off-by: Kalle Valo <kvalo(a)qca.qualcomm.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/wireless/ath/ath10k/wmi-tlv.c | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) --- a/drivers/net/wireless/ath/ath10k/wmi-tlv.c +++ b/drivers/net/wireless/ath/ath10k/wmi-tlv.c @@ -1105,8 +1105,10 @@ static int ath10k_wmi_tlv_op_pull_fw_sta struct ath10k_fw_stats_pdev *dst; src = data; - if (data_len < sizeof(*src)) + if (data_len < sizeof(*src)) { + kfree(tb); return -EPROTO; + } data += sizeof(*src); data_len -= sizeof(*src); @@ -1126,8 +1128,10 @@ static int ath10k_wmi_tlv_op_pull_fw_sta struct ath10k_fw_stats_vdev *dst; src = data; - if (data_len < sizeof(*src)) + if (data_len < sizeof(*src)) { + kfree(tb); return -EPROTO; + } data += sizeof(*src); data_len -= sizeof(*src); @@ -1145,8 +1149,10 @@ static int ath10k_wmi_tlv_op_pull_fw_sta struct ath10k_fw_stats_peer *dst; src = data; - if (data_len < sizeof(*src)) + if (data_len < sizeof(*src)) { + kfree(tb); return -EPROTO; + } data += sizeof(*src); data_len -= sizeof(*src); Patches currently in stable-queue which might be from chunkeey(a)googlemail.com are queue-4.9/p54-don-t-unregister-leds-when-they-are-not-initialized.patch queue-4.9/ath10k-fix-potential-memory-leak-in-ath10k_wmi_tlv_op_pull_fw_stats.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "ath10k: fix incorrect txpower set by P2P_DEVICE interface" 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 ath10k: fix incorrect txpower set by P2P_DEVICE interface 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: ath10k-fix-incorrect-txpower-set-by-p2p_device-interface.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 Tue Nov 28 10:49:28 CET 2017 From: Ryan Hsu <ryanhsu(a)qca.qualcomm.com> Date: Tue, 13 Dec 2016 14:55:19 -0800 Subject: ath10k: fix incorrect txpower set by P2P_DEVICE interface From: Ryan Hsu <ryanhsu(a)qca.qualcomm.com> [ Upstream commit 88407beb1b1462f706a1950a355fd086e1c450b6 ] Ath10k reports the phy capability that supports P2P_DEVICE interface. When we use the P2P supported wpa_supplicant to start connection, it'll create two interfaces, one is wlan0 (vdev_id=0) and one is P2P_DEVICE p2p-dev-wlan0 which is for p2p control channel (vdev_id=1). ath10k_pci mac vdev create 0 (add interface) type 2 subtype 0 ath10k_add_interface: vdev_id: 0, txpower: 0, bss_power: 0 ... ath10k_pci mac vdev create 1 (add interface) type 2 subtype 1 ath10k_add_interface: vdev_id: 1, txpower: 0, bss_power: 0 And the txpower in per vif bss_conf will only be set to valid tx power when the interface is assigned with channel_ctx. But this P2P_DEVICE interface will never be used for any connection, so that the uninitialized bss_conf.txpower=0 is assinged to the arvif->txpower when interface created. Since the txpower configuration is firmware per physical interface. So the smallest txpower of all vifs will be the one limit the tx power of the physical device, that causing the low txpower issue on other active interfaces. wlan0: Limiting TX power to 21 (24 - 3) dBm ath10k_pci mac vdev_id 0 txpower 21 ath10k_mac_txpower_recalc: vdev_id: 1, txpower: 0 ath10k_mac_txpower_recalc: vdev_id: 0, txpower: 21 ath10k_pci mac txpower 0 This issue only happens when we use the wpa_supplicant that supports P2P or if we use the iw tool to create the control P2P_DEVICE interface. Signed-off-by: Ryan Hsu <ryanhsu(a)qca.qualcomm.com> Signed-off-by: Kalle Valo <kvalo(a)qca.qualcomm.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/wireless/ath/ath10k/mac.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) --- a/drivers/net/wireless/ath/ath10k/mac.c +++ b/drivers/net/wireless/ath/ath10k/mac.c @@ -4668,7 +4668,8 @@ static int ath10k_mac_txpower_recalc(str lockdep_assert_held(&ar->conf_mutex); list_for_each_entry(arvif, &ar->arvifs, list) { - WARN_ON(arvif->txpower < 0); + if (arvif->txpower <= 0) + continue; if (txpower == -1) txpower = arvif->txpower; @@ -4676,8 +4677,8 @@ static int ath10k_mac_txpower_recalc(str txpower = min(txpower, arvif->txpower); } - if (WARN_ON(txpower == -1)) - return -EINVAL; + if (txpower == -1) + return 0; ret = ath10k_mac_txpower_setup(ar, txpower); if (ret) { Patches currently in stable-queue which might be from ryanhsu(a)qca.qualcomm.com are queue-4.9/ath10k-fix-incorrect-txpower-set-by-p2p_device-interface.patch queue-4.9/ath10k-ignore-configuring-the-incorrect-board_id.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "ASoC: wm_adsp: Don't overrun firmware file buffer when reading region 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 ASoC: wm_adsp: Don't overrun firmware file buffer when reading region 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: asoc-wm_adsp-don-t-overrun-firmware-file-buffer-when-reading-region-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 Tue Nov 28 10:49:28 CET 2017 From: Richard Fitzgerald <rf(a)opensource.wolfsonmicro.com> Date: Tue, 20 Dec 2016 10:29:12 +0000 Subject: ASoC: wm_adsp: Don't overrun firmware file buffer when reading region data From: Richard Fitzgerald <rf(a)opensource.wolfsonmicro.com> [ Upstream commit 1cab2a84f470e15ecc8e5143bfe9398c6e888032 ] Protect against corrupt firmware files by ensuring that the length we get for the data in a region actually lies within the available firmware file data buffer. Signed-off-by: Richard Fitzgerald <rf(a)opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- sound/soc/codecs/wm_adsp.c | 25 ++++++++++++++++++++++++- 1 file changed, 24 insertions(+), 1 deletion(-) --- a/sound/soc/codecs/wm_adsp.c +++ b/sound/soc/codecs/wm_adsp.c @@ -1365,7 +1365,7 @@ static int wm_adsp_load(struct wm_adsp * const struct wmfw_region *region; const struct wm_adsp_region *mem; const char *region_name; - char *file, *text; + char *file, *text = NULL; struct wm_adsp_buf *buf; unsigned int reg; int regions = 0; @@ -1526,10 +1526,21 @@ static int wm_adsp_load(struct wm_adsp * regions, le32_to_cpu(region->len), offset, region_name); + if ((pos + le32_to_cpu(region->len) + sizeof(*region)) > + firmware->size) { + adsp_err(dsp, + "%s.%d: %s region len %d bytes exceeds file length %zu\n", + file, regions, region_name, + le32_to_cpu(region->len), firmware->size); + ret = -EINVAL; + goto out_fw; + } + if (text) { memcpy(text, region->data, le32_to_cpu(region->len)); adsp_info(dsp, "%s: %s\n", file, text); kfree(text); + text = NULL; } if (reg) { @@ -1574,6 +1585,7 @@ out_fw: regmap_async_complete(regmap); wm_adsp_buf_free(&buf_list); release_firmware(firmware); + kfree(text); out: kfree(file); @@ -2054,6 +2066,17 @@ static int wm_adsp_load_coeff(struct wm_ } if (reg) { + if ((pos + le32_to_cpu(blk->len) + sizeof(*blk)) > + firmware->size) { + adsp_err(dsp, + "%s.%d: %s region len %d bytes exceeds file length %zu\n", + file, blocks, region_name, + le32_to_cpu(blk->len), + firmware->size); + ret = -EINVAL; + goto out_fw; + } + buf = wm_adsp_buf_alloc(blk->data, le32_to_cpu(blk->len), &buf_list); Patches currently in stable-queue which might be from rf(a)opensource.wolfsonmicro.com are queue-4.9/asoc-wm_adsp-don-t-overrun-firmware-file-buffer-when-reading-region-data.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "ASoC: rsnd: don't double free kctrl" 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 ASoC: rsnd: don't double free kctrl 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: asoc-rsnd-don-t-double-free-kctrl.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 Tue Nov 28 10:49:28 CET 2017 From: Colin Ian King <colin.king(a)canonical.com> Date: Thu, 8 Dec 2016 13:05:43 +0000 Subject: ASoC: rsnd: don't double free kctrl From: Colin Ian King <colin.king(a)canonical.com> [ Upstream commit 0ea617a298dcdc2251b4e10f83ac3f3e627b66e3 ] On an error, snd_ctl_add already free's kctrl, so calling snd_ctl_free_one to free it again leads to a double free error. Fix this by removing the extraneous snd_ctl_free_one call. Issue found using static analysis with CoverityScan, CID 1372908 Signed-off-by: Colin Ian King <colin.king(a)canonical.com> Acked-by: Kuninori Morimoto <kuninori.morimoto.gx(a)renesas.com> Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- sound/soc/sh/rcar/core.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) --- a/sound/soc/sh/rcar/core.c +++ b/sound/soc/sh/rcar/core.c @@ -978,10 +978,8 @@ static int __rsnd_kctrl_new(struct rsnd_ return -ENOMEM; ret = snd_ctl_add(card, kctrl); - if (ret < 0) { - snd_ctl_free_one(kctrl); + if (ret < 0) return ret; - } cfg->update = update; cfg->card = card; Patches currently in stable-queue which might be from colin.king(a)canonical.com are queue-4.9/asoc-rsnd-don-t-double-free-kctrl.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "ALSA: hda - Apply ALC269_FIXUP_NO_SHUTUP on HDA_FIXUP_ACT_PROBE" 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 ALSA: hda - Apply ALC269_FIXUP_NO_SHUTUP on HDA_FIXUP_ACT_PROBE 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: alsa-hda-apply-alc269_fixup_no_shutup-on-hda_fixup_act_probe.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 Tue Nov 28 10:49:28 CET 2017 From: Gabriele Mazzotta <gabriele.mzt(a)gmail.com> Date: Sat, 24 Dec 2016 19:50:00 +0100 Subject: ALSA: hda - Apply ALC269_FIXUP_NO_SHUTUP on HDA_FIXUP_ACT_PROBE From: Gabriele Mazzotta <gabriele.mzt(a)gmail.com> [ Upstream commit 972aa2c708703c21f14eb958b37e82aae2530e44 ] Setting shutup when the action is HDA_FIXUP_ACT_PRE_PROBE might not have the desired effect since it could be overridden by another more generic shutup function. Prevent this by setting the more specific shutup function on HDA_FIXUP_ACT_PROBE. Signed-off-by: Gabriele Mazzotta <gabriele.mzt(a)gmail.com> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- sound/pci/hda/patch_realtek.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -4419,7 +4419,7 @@ static void alc_no_shutup(struct hda_cod static void alc_fixup_no_shutup(struct hda_codec *codec, const struct hda_fixup *fix, int action) { - if (action == HDA_FIXUP_ACT_PRE_PROBE) { + if (action == HDA_FIXUP_ACT_PROBE) { struct alc_spec *spec = codec->spec; spec->shutup = alc_no_shutup; } Patches currently in stable-queue which might be from gabriele.mzt(a)gmail.com are queue-4.9/alsa-hda-apply-alc269_fixup_no_shutup-on-hda_fixup_act_probe.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "adm80211: return an error if adm8211_alloc_rings() 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 adm80211: return an error if adm8211_alloc_rings() 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: adm80211-return-an-error-if-adm8211_alloc_rings-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 Tue Nov 28 10:49:28 CET 2017 From: Dan Carpenter <dan.carpenter(a)oracle.com> Date: Wed, 7 Dec 2016 14:21:22 +0300 Subject: adm80211: return an error if adm8211_alloc_rings() fails From: Dan Carpenter <dan.carpenter(a)oracle.com> [ Upstream commit c705a6b3aa7804d7bc6660183f51e510c61dc807 ] We accidentally return success when adm8211_alloc_rings() fails but we should preserve the error code. Fixes: cc0b88cf5ecf ("[PATCH] Add adm8211 802.11b wireless driver") Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.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/admtek/adm8211.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/drivers/net/wireless/admtek/adm8211.c +++ b/drivers/net/wireless/admtek/adm8211.c @@ -1843,7 +1843,8 @@ static int adm8211_probe(struct pci_dev priv->rx_ring_size = rx_ring_size; priv->tx_ring_size = tx_ring_size; - if (adm8211_alloc_rings(dev)) { + err = adm8211_alloc_rings(dev); + if (err) { printk(KERN_ERR "%s (adm8211): Cannot allocate TX/RX ring\n", pci_name(pdev)); goto err_iounmap; Patches currently in stable-queue which might be from dan.carpenter(a)oracle.com are queue-4.9/ecryptfs-use-after-free-in-ecryptfs_release_messaging.patch queue-4.9/adm80211-return-an-error-if-adm8211_alloc_rings-fails.patch queue-4.9/nfc-fix-device-allocation-error-return.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "adm80211: add checks for dma mapping errors" 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 adm80211: add checks for dma mapping errors 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: adm80211-add-checks-for-dma-mapping-errors.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 Tue Nov 28 10:49:28 CET 2017 From: Alexey Khoroshilov <khoroshilov(a)ispras.ru> Date: Sat, 3 Dec 2016 00:52:46 +0300 Subject: adm80211: add checks for dma mapping errors From: Alexey Khoroshilov <khoroshilov(a)ispras.ru> [ Upstream commit d15697de60db5570532fdedb8e13b2251d65b8e3 ] The driver does not check if mapping dma memory succeed. The patch adds the checks and failure handling. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Alexey Khoroshilov <khoroshilov(a)ispras.ru> 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/admtek/adm8211.c | 24 ++++++++++++++++++++++-- 1 file changed, 22 insertions(+), 2 deletions(-) --- a/drivers/net/wireless/admtek/adm8211.c +++ b/drivers/net/wireless/admtek/adm8211.c @@ -413,6 +413,13 @@ static void adm8211_interrupt_rci(struct skb_tail_pointer(newskb), RX_PKT_SIZE, PCI_DMA_FROMDEVICE); + if (pci_dma_mapping_error(priv->pdev, + priv->rx_buffers[entry].mapping)) { + priv->rx_buffers[entry].skb = NULL; + dev_kfree_skb(newskb); + skb = NULL; + /* TODO: update rx dropped stats */ + } } else { skb = NULL; /* TODO: update rx dropped stats */ @@ -1450,6 +1457,12 @@ static int adm8211_init_rings(struct iee skb_tail_pointer(rx_info->skb), RX_PKT_SIZE, PCI_DMA_FROMDEVICE); + if (pci_dma_mapping_error(priv->pdev, rx_info->mapping)) { + dev_kfree_skb(rx_info->skb); + rx_info->skb = NULL; + break; + } + desc->buffer1 = cpu_to_le32(rx_info->mapping); desc->status = cpu_to_le32(RDES0_STATUS_OWN | RDES0_STATUS_SQL); } @@ -1613,7 +1626,7 @@ static void adm8211_calc_durations(int * } /* Transmit skb w/adm8211_tx_hdr (802.11 header created by hardware) */ -static void adm8211_tx_raw(struct ieee80211_hw *dev, struct sk_buff *skb, +static int adm8211_tx_raw(struct ieee80211_hw *dev, struct sk_buff *skb, u16 plcp_signal, size_t hdrlen) { @@ -1625,6 +1638,8 @@ static void adm8211_tx_raw(struct ieee80 mapping = pci_map_single(priv->pdev, skb->data, skb->len, PCI_DMA_TODEVICE); + if (pci_dma_mapping_error(priv->pdev, mapping)) + return -ENOMEM; spin_lock_irqsave(&priv->lock, flags); @@ -1657,6 +1672,8 @@ static void adm8211_tx_raw(struct ieee80 /* Trigger transmit poll */ ADM8211_CSR_WRITE(TDR, 0); + + return 0; } /* Put adm8211_tx_hdr on skb and transmit */ @@ -1710,7 +1727,10 @@ static void adm8211_tx(struct ieee80211_ txhdr->retry_limit = info->control.rates[0].count; - adm8211_tx_raw(dev, skb, plcp_signal, hdrlen); + if (adm8211_tx_raw(dev, skb, plcp_signal, hdrlen)) { + /* Drop packet */ + ieee80211_free_txskb(dev, skb); + } } static int adm8211_alloc_rings(struct ieee80211_hw *dev) Patches currently in stable-queue which might be from khoroshilov(a)ispras.ru are queue-4.9/adm80211-add-checks-for-dma-mapping-errors.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "Revert "drm/i915: Do not rely on wm preservation for ILK watermarks"" 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 "drm/i915: Do not rely on wm preservation for ILK watermarks" 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-drm-i915-do-not-rely-on-wm-preservation-for-ilk-watermarks.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 Tue Nov 28 10:15:23 CET 2017 Date: Tue, 28 Nov 2017 10:15:23 +0100 To: Greg KH <gregkh(a)linuxfoundation.org> From: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Subject: Revert "drm/i915: Do not rely on wm preservation for ILK watermarks" This reverts commit 7de694782cbe7840f2c0de6f1e70f41fc1b8b6e8 which is commit 8777b927b92cf5b6c29f9f9d3c737addea9ac8a7 upstream. It was reported to cause flickering and other regressions. Reported-by: Rainer Fiebig <jrf(a)mailbox.org> Cc: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com> Cc: Ville Syrjälä <ville.syrjala(a)linux.intel.com> Cc: Matt Roper <matthew.d.roper(a)intel.com> Cc: Rodrigo Vivi <rodrigo.vivi(a)intel.com> Cc: Jani Nikula <jani.nikula(a)linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> reverted: --- drivers/gpu/drm/i915/intel_drv.h | 1 drivers/gpu/drm/i915/intel_pm.c | 52 ++++++++++++++++++++++----------------- 2 files changed, 31 insertions(+), 22 deletions(-) --- a/drivers/gpu/drm/i915/intel_drv.h +++ b/drivers/gpu/drm/i915/intel_drv.h @@ -457,6 +457,7 @@ struct intel_crtc_scaler_state { struct intel_pipe_wm { struct intel_wm_level wm[5]; + struct intel_wm_level raw_wm[5]; uint32_t linetime; bool fbc_wm_enabled; bool pipe_enabled; --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -27,7 +27,6 @@ #include <linux/cpufreq.h> #include <drm/drm_plane_helper.h> -#include <drm/drm_atomic_helper.h> #include "i915_drv.h" #include "intel_drv.h" #include "../../../platform/x86/intel_ips.h" @@ -2018,9 +2017,9 @@ static void ilk_compute_wm_level(const s const struct intel_crtc *intel_crtc, int level, struct intel_crtc_state *cstate, - const struct intel_plane_state *pristate, - const struct intel_plane_state *sprstate, - const struct intel_plane_state *curstate, + struct intel_plane_state *pristate, + struct intel_plane_state *sprstate, + struct intel_plane_state *curstate, struct intel_wm_level *result) { uint16_t pri_latency = dev_priv->wm.pri_latency[level]; @@ -2342,24 +2341,28 @@ static int ilk_compute_pipe_wm(struct in struct intel_pipe_wm *pipe_wm; struct drm_device *dev = state->dev; const struct drm_i915_private *dev_priv = to_i915(dev); - struct drm_plane *plane; - const struct drm_plane_state *plane_state; - const struct intel_plane_state *pristate = NULL; - const struct intel_plane_state *sprstate = NULL; - const struct intel_plane_state *curstate = NULL; + struct intel_plane *intel_plane; + struct intel_plane_state *pristate = NULL; + struct intel_plane_state *sprstate = NULL; + struct intel_plane_state *curstate = NULL; int level, max_level = ilk_wm_max_level(dev), usable_level; struct ilk_wm_maximums max; pipe_wm = &cstate->wm.ilk.optimal; - drm_atomic_crtc_state_for_each_plane_state(plane, plane_state, &cstate->base) { - const struct intel_plane_state *ps = to_intel_plane_state(plane_state); + for_each_intel_plane_on_crtc(dev, intel_crtc, intel_plane) { + struct intel_plane_state *ps; - if (plane->type == DRM_PLANE_TYPE_PRIMARY) + ps = intel_atomic_get_existing_plane_state(state, + intel_plane); + if (!ps) + continue; + + if (intel_plane->base.type == DRM_PLANE_TYPE_PRIMARY) pristate = ps; - else if (plane->type == DRM_PLANE_TYPE_OVERLAY) + else if (intel_plane->base.type == DRM_PLANE_TYPE_OVERLAY) sprstate = ps; - else if (plane->type == DRM_PLANE_TYPE_CURSOR) + else if (intel_plane->base.type == DRM_PLANE_TYPE_CURSOR) curstate = ps; } @@ -2381,9 +2384,11 @@ static int ilk_compute_pipe_wm(struct in if (pipe_wm->sprites_scaled) usable_level = 0; - memset(&pipe_wm->wm, 0, sizeof(pipe_wm->wm)); ilk_compute_wm_level(dev_priv, intel_crtc, 0, cstate, - pristate, sprstate, curstate, &pipe_wm->wm[0]); + pristate, sprstate, curstate, &pipe_wm->raw_wm[0]); + + memset(&pipe_wm->wm, 0, sizeof(pipe_wm->wm)); + pipe_wm->wm[0] = pipe_wm->raw_wm[0]; if (IS_HASWELL(dev) || IS_BROADWELL(dev)) pipe_wm->linetime = hsw_compute_linetime_wm(cstate); @@ -2393,8 +2398,8 @@ static int ilk_compute_pipe_wm(struct in ilk_compute_wm_reg_maximums(dev, 1, &max); - for (level = 1; level <= usable_level; level++) { - struct intel_wm_level *wm = &pipe_wm->wm[level]; + for (level = 1; level <= max_level; level++) { + struct intel_wm_level *wm = &pipe_wm->raw_wm[level]; ilk_compute_wm_level(dev_priv, intel_crtc, level, cstate, pristate, sprstate, curstate, wm); @@ -2404,10 +2409,13 @@ static int ilk_compute_pipe_wm(struct in * register maximums since such watermarks are * always invalid. */ - if (!ilk_validate_wm_level(level, &max, wm)) { - memset(wm, 0, sizeof(*wm)); - break; - } + if (level > usable_level) + continue; + + if (ilk_validate_wm_level(level, &max, wm)) + pipe_wm->wm[level] = *wm; + else + usable_level = level; } return 0; Patches currently in stable-queue which might be from gregkh(a)linuxfoundation.org are queue-4.9/sched-make-resched_cpu-unconditional.patch queue-4.9/media-rc-check-for-integer-overflow.patch queue-4.9/kvm-nvmx-set-idtr-and-gdtr-limits-when-loading-l1-host-state.patch queue-4.9/rtlwifi-fix-uninitialized-rtlhal-last_suspend_sec-time.patch queue-4.9/libnvdimm-pfn-make-resource-attribute-only-readable-by-root.patch queue-4.9/mips-fix-an-n32-core-file-generation-regset-support-regression.patch queue-4.9/x86-decoder-add-new-test-instruction-pattern.patch queue-4.9/mtd-nand-fix-writing-mtdoops-to-nand-flash.patch queue-4.9/i40evf-use-smp_rmb-rather-than-read_barrier_depends.patch queue-4.9/revert-drm-i915-do-not-rely-on-wm-preservation-for-ilk-watermarks.patch queue-4.9/ecryptfs-use-after-free-in-ecryptfs_release_messaging.patch queue-4.9/s390-disassembler-add-missing-end-marker-for-e7-table.patch queue-4.9/dm-allocate-struct-mapped_device-with-kvzalloc.patch queue-4.9/kvm-svm-obey-guest-pat.patch queue-4.9/block-fix-a-race-between-blk_cleanup_queue-and-timeout-handling.patch queue-4.9/cx231xx-cards-fix-null-deref-on-missing-association-descriptor.patch queue-4.9/s390-disassembler-increase-show_code-buffer-size.patch queue-4.9/alsa-timer-remove-kernel-warning-at-compat-ioctl-error-paths.patch queue-4.9/igb-use-smp_rmb-rather-than-read_barrier_depends.patch queue-4.9/mtd-nand-mtk-fix-infinite-ecc-decode-irq-issue.patch queue-4.9/s390-fix-transactional-execution-control-register-handling.patch queue-4.9/lib-mpi-call-cond_resched-from-mpi_powm-loop.patch queue-4.9/nfs-avoid-rcu-usage-in-tracepoints.patch queue-4.9/alsa-hda-add-raven-pci-id.patch queue-4.9/dm-fix-race-between-dm_get_from_kobject-and-__dm_destroy.patch queue-4.9/clk-ti-dra7-atl-clock-fix-child-node-lookups.patch queue-4.9/arm-8722-1-mm-make-strict_kernel_rwx-effective-for-lpae.patch queue-4.9/nfs-fix-ugly-referral-attributes.patch queue-4.9/target-fix-queue_full-scsi-task-attribute-handling.patch queue-4.9/mips-bcm47xx-fix-led-inversion-for-wrt54gsv1.patch queue-4.9/vsock-use-new-wait-api-for-vsock_stream_sendmsg.patch queue-4.9/lockd-double-unregister-of-inetaddr-notifiers.patch queue-4.9/autofs-don-t-fail-mount-for-transient-error.patch queue-4.9/net-9p-switch-to-wait_event_killable.patch queue-4.9/media-v4l2-ctrl-fix-flags-field-on-control-events.patch queue-4.9/p54-don-t-unregister-leds-when-they-are-not-initialized.patch queue-4.9/e1000e-fix-error-path-in-link-detection.patch queue-4.9/mips-ralink-fix-mt7628-pinmux.patch queue-4.9/e1000e-separate-signaling-for-link-check-link-up.patch queue-4.9/x86-entry-64-add-missing-irqflags-tracing-to-native_load_gs_index.patch queue-4.9/iscsi-target-fix-non-immediate-tmr-reference-leak.patch queue-4.9/alsa-usb-audio-add-sanity-checks-in-v2-clock-parsers.patch queue-4.9/rt2x00usb-mark-device-removed-when-get-enoent-usb-error.patch queue-4.9/isofs-fix-timestamps-beyond-2027.patch queue-4.9/nfs-fix-typo-in-nomigration-mount-option.patch queue-4.9/alsa-hda-fix-too-short-hdmi-dp-chmap-reporting.patch queue-4.9/fs-9p-compare-qid.path-in-v9fs_test_inode.patch queue-4.9/x86-mm-fix-use-after-free-of-vma-during-userfaultfd-fault.patch queue-4.9/alsa-hda-realtek-fix-alc700-family-no-sound-issue.patch queue-4.9/pm-opp-add-missing-of_node_put-np.patch queue-4.9/ixgbevf-use-smp_rmb-rather-than-read_barrier_depends.patch queue-4.9/sched-rt-simplify-the-ipi-based-rt-balancing-logic.patch queue-4.9/igbvf-use-smp_rmb-rather-than-read_barrier_depends.patch queue-4.9/e1000e-fix-return-value-test.patch queue-4.9/s390-runtime-instrumention-fix-possible-memory-corruption.patch queue-4.9/nfsd-deal-with-revoked-delegations-appropriately.patch queue-4.9/arm-8721-1-mm-dump-check-hardware-ro-bit-for-lpae.patch queue-4.9/ata-fixes-kernel-crash-while-tracing-ata_eh_link_autopsy-event.patch queue-4.9/ipv6-only-call-ip6_route_dev_notify-once-for-netdev_unregister.patch queue-4.9/fm10k-use-smp_rmb-rather-than-read_barrier_depends.patch queue-4.9/pci-set-cavium-acs-capability-quirk-flags-to-assert-rr-cr-sv-uf.patch queue-4.9/bcache-check-ca-alloc_thread-initialized-before-wake-up-it.patch queue-4.9/ixgbe-fix-skb-list-corruption-on-power-systems.patch queue-4.9/alsa-usb-audio-fix-potential-out-of-bound-access-at-parsing-su.patch queue-4.9/mips-fix-odd-fp-register-warnings-with-mips64r2.patch queue-4.9/acpi-ec-fix-regression-related-to-triggering-source-of-ec-event-handling.patch queue-4.9/alsa-pcm-update-tstamp-only-if-audio_tstamp-changed.patch queue-4.9/fscrypt-lock-mutex-before-checking-for-bounce-page-pool.patch queue-4.9/parisc-fix-validity-check-of-pointer-size-argument-in-new-cas-implementation.patch queue-4.9/e1000e-avoid-receiver-overrun-interrupt-bursts.patch queue-4.9/mips-pci-remove-kern_warn-instance-inside-the-mt7620-driver.patch queue-4.9/fix-a-page-leak-in-vhost_scsi_iov_to_sgl-error-recovery.patch queue-4.9/mips-ralink-fix-typo-in-mt7628-pinmux-function.patch queue-4.9/powerpc-signal-properly-handle-return-value-from-uprobe_deny_signal.patch queue-4.9/dm-bufio-fix-integer-overflow-when-limiting-maximum-cache-size.patch queue-4.9/mips-dts-remove-bogus-bcm96358nb4ser.dtb-from-dtb-y-entry.patch queue-4.9/nilfs2-fix-race-condition-that-causes-file-system-corruption.patch queue-4.9/ib-srp-avoid-that-a-cable-pull-can-trigger-a-kernel-crash.patch queue-4.9/irqchip-gic-v3-fix-ppi-partitions-lookup.patch queue-4.9/libnvdimm-namespace-make-resource-attribute-only-readable-by-root.patch queue-4.9/ib-srpt-do-not-accept-invalid-initiator-port-names.patch queue-4.9/nfc-fix-device-allocation-error-return.patch queue-4.9/rtlwifi-rtl8192ee-fix-memory-leak-when-loading-firmware.patch queue-4.9/arm64-implement-arch-specific-pte_access_permitted.patch queue-4.9/mtd-nand-omap2-fix-subpage-write.patch queue-4.9/libceph-don-t-warn-if-user-tries-to-add-invalid-key.patch queue-4.9/media-don-t-do-dma-on-stack-for-firmware-upload-in-the-as102-driver.patch queue-4.9/i40e-use-smp_rmb-rather-than-read_barrier_depends.patch queue-4.9/libnvdimm-namespace-fix-label-initialization-to-use-valid-seq-numbers.patch queue-4.9/alsa-usb-audio-add-sanity-checks-to-fe-parser.patch queue-4.9/sunrpc-fix-tracepoint-storage-issues-with-svc_recv-and-svc_rqst_status.patch queue-4.9/ext4-fix-interaction-between-i_size-fallocate-and-delalloc-after-a-crash.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "e1000e: Separate signaling for link check/link up" 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 e1000e: Separate signaling for link check/link up 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: e1000e-separate-signaling-for-link-check-link-up.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 19110cfbb34d4af0cdfe14cd243f3b09dc95b013 Mon Sep 17 00:00:00 2001 From: Benjamin Poirier <bpoirier(a)suse.com> Date: Fri, 21 Jul 2017 11:36:26 -0700 Subject: e1000e: Separate signaling for link check/link up From: Benjamin Poirier <bpoirier(a)suse.com> commit 19110cfbb34d4af0cdfe14cd243f3b09dc95b013 upstream. Lennart reported the following race condition: \ e1000_watchdog_task \ e1000e_has_link \ hw->mac.ops.check_for_link() === e1000e_check_for_copper_link /* link is up */ mac->get_link_status = false; /* interrupt */ \ e1000_msix_other hw->mac.get_link_status = true; link_active = !hw->mac.get_link_status /* link_active is false, wrongly */ This problem arises because the single flag get_link_status is used to signal two different states: link status needs checking and link status is down. Avoid the problem by using the return value of .check_for_link to signal the link status to e1000e_has_link(). Reported-by: Lennart Sorensen <lsorense(a)csclub.uwaterloo.ca> Signed-off-by: Benjamin Poirier <bpoirier(a)suse.com> Tested-by: Aaron Brown <aaron.f.brown(a)intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher(a)intel.com> Signed-off-by: Amit Pundir <amit.pundir(a)linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/intel/e1000e/mac.c | 11 ++++++++--- drivers/net/ethernet/intel/e1000e/netdev.c | 2 +- 2 files changed, 9 insertions(+), 4 deletions(-) --- a/drivers/net/ethernet/intel/e1000e/mac.c +++ b/drivers/net/ethernet/intel/e1000e/mac.c @@ -410,6 +410,9 @@ void e1000e_clear_hw_cntrs_base(struct e * Checks to see of the link status of the hardware has changed. If a * change in link status has been detected, then we read the PHY registers * to get the current speed/duplex if link exists. + * + * Returns a negative error code (-E1000_ERR_*) or 0 (link down) or 1 (link + * up). **/ s32 e1000e_check_for_copper_link(struct e1000_hw *hw) { @@ -423,7 +426,7 @@ s32 e1000e_check_for_copper_link(struct * Change or Rx Sequence Error interrupt. */ if (!mac->get_link_status) - return 0; + return 1; /* First we want to see if the MII Status Register reports * link. If so, then we want to get the current speed/duplex @@ -461,10 +464,12 @@ s32 e1000e_check_for_copper_link(struct * different link partner. */ ret_val = e1000e_config_fc_after_link_up(hw); - if (ret_val) + if (ret_val) { e_dbg("Error configuring flow control\n"); + return ret_val; + } - return ret_val; + return 1; } /** --- a/drivers/net/ethernet/intel/e1000e/netdev.c +++ b/drivers/net/ethernet/intel/e1000e/netdev.c @@ -5056,7 +5056,7 @@ static bool e1000e_has_link(struct e1000 case e1000_media_type_copper: if (hw->mac.get_link_status) { ret_val = hw->mac.ops.check_for_link(hw); - link_active = !hw->mac.get_link_status; + link_active = ret_val > 0; } else { link_active = true; } Patches currently in stable-queue which might be from bpoirier(a)suse.com are queue-4.9/e1000e-fix-error-path-in-link-detection.patch queue-4.9/e1000e-separate-signaling-for-link-check-link-up.patch queue-4.9/e1000e-fix-return-value-test.patch queue-4.9/e1000e-avoid-receiver-overrun-interrupt-bursts.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "e1000e: Fix return value test" 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 e1000e: Fix return value test 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: e1000e-fix-return-value-test.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 d3509f8bc7b0560044c15f0e3ecfde1d9af757a6 Mon Sep 17 00:00:00 2001 From: Benjamin Poirier <bpoirier(a)suse.com> Date: Fri, 21 Jul 2017 11:36:25 -0700 Subject: e1000e: Fix return value test From: Benjamin Poirier <bpoirier(a)suse.com> commit d3509f8bc7b0560044c15f0e3ecfde1d9af757a6 upstream. All the helpers return -E1000_ERR_PHY. Signed-off-by: Benjamin Poirier <bpoirier(a)suse.com> Tested-by: Aaron Brown <aaron.f.brown(a)intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher(a)intel.com> Signed-off-by: Amit Pundir <amit.pundir(a)linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/intel/e1000e/netdev.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/net/ethernet/intel/e1000e/netdev.c +++ b/drivers/net/ethernet/intel/e1000e/netdev.c @@ -5074,7 +5074,7 @@ static bool e1000e_has_link(struct e1000 break; } - if ((ret_val == E1000_ERR_PHY) && (hw->phy.type == e1000_phy_igp_3) && + if ((ret_val == -E1000_ERR_PHY) && (hw->phy.type == e1000_phy_igp_3) && (er32(CTRL) & E1000_PHY_CTRL_GBE_DISABLE)) { /* See e1000_kmrn_lock_loss_workaround_ich8lan() */ e_info("Gigabit has been disabled, downgrading speed\n"); Patches currently in stable-queue which might be from bpoirier(a)suse.com are queue-4.9/e1000e-fix-error-path-in-link-detection.patch queue-4.9/e1000e-separate-signaling-for-link-check-link-up.patch queue-4.9/e1000e-fix-return-value-test.patch queue-4.9/e1000e-avoid-receiver-overrun-interrupt-bursts.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "e1000e: Fix error path in link detection" 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 e1000e: Fix error path in link detection 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: e1000e-fix-error-path-in-link-detection.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 c4c40e51f9c32c6dd8adf606624c930a1c4d9bbb Mon Sep 17 00:00:00 2001 From: Benjamin Poirier <bpoirier(a)suse.com> Date: Fri, 21 Jul 2017 11:36:23 -0700 Subject: e1000e: Fix error path in link detection From: Benjamin Poirier <bpoirier(a)suse.com> commit c4c40e51f9c32c6dd8adf606624c930a1c4d9bbb upstream. In case of error from e1e_rphy(), the loop will exit early and "success" will be set to true erroneously. Signed-off-by: Benjamin Poirier <bpoirier(a)suse.com> Tested-by: Aaron Brown <aaron.f.brown(a)intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher(a)intel.com> Signed-off-by: Amit Pundir <amit.pundir(a)linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/intel/e1000e/phy.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) --- a/drivers/net/ethernet/intel/e1000e/phy.c +++ b/drivers/net/ethernet/intel/e1000e/phy.c @@ -1744,6 +1744,7 @@ s32 e1000e_phy_has_link_generic(struct e s32 ret_val = 0; u16 i, phy_status; + *success = false; for (i = 0; i < iterations; i++) { /* Some PHYs require the MII_BMSR register to be read * twice due to the link bit being sticky. No harm doing @@ -1763,16 +1764,16 @@ s32 e1000e_phy_has_link_generic(struct e ret_val = e1e_rphy(hw, MII_BMSR, &phy_status); if (ret_val) break; - if (phy_status & BMSR_LSTATUS) + if (phy_status & BMSR_LSTATUS) { + *success = true; break; + } if (usec_interval >= 1000) msleep(usec_interval / 1000); else udelay(usec_interval); } - *success = (i < iterations); - return ret_val; } Patches currently in stable-queue which might be from bpoirier(a)suse.com are queue-4.9/e1000e-fix-error-path-in-link-detection.patch queue-4.9/e1000e-separate-signaling-for-link-check-link-up.patch queue-4.9/e1000e-fix-return-value-test.patch queue-4.9/e1000e-avoid-receiver-overrun-interrupt-bursts.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "e1000e: Avoid receiver overrun interrupt bursts" 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 e1000e: Avoid receiver overrun interrupt bursts 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: e1000e-avoid-receiver-overrun-interrupt-bursts.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 4aea7a5c5e940c1723add439f4088844cd26196d Mon Sep 17 00:00:00 2001 From: Benjamin Poirier <bpoirier(a)suse.com> Date: Fri, 21 Jul 2017 11:36:27 -0700 Subject: e1000e: Avoid receiver overrun interrupt bursts From: Benjamin Poirier <bpoirier(a)suse.com> commit 4aea7a5c5e940c1723add439f4088844cd26196d upstream. When e1000e_poll() is not fast enough to keep up with incoming traffic, the adapter (when operating in msix mode) raises the Other interrupt to signal Receiver Overrun. This is a double problem because 1) at the moment e1000_msix_other() assumes that it is only called in case of Link Status Change and 2) if the condition persists, the interrupt is repeatedly raised again in quick succession. Ideally we would configure the Other interrupt to not be raised in case of receiver overrun but this doesn't seem possible on this adapter. Instead, we handle the first part of the problem by reverting to the practice of reading ICR in the other interrupt handler, like before commit 16ecba59bc33 ("e1000e: Do not read ICR in Other interrupt"). Thanks to commit 0a8047ac68e5 ("e1000e: Fix msi-x interrupt automask") which cleared IAME from CTRL_EXT, reading ICR doesn't interfere with RxQ0, TxQ0 interrupts anymore. We handle the second part of the problem by not re-enabling the Other interrupt right away when there is overrun. Instead, we wait until traffic subsides, napi polling mode is exited and interrupts are re-enabled. Reported-by: Lennart Sorensen <lsorense(a)csclub.uwaterloo.ca> Fixes: 16ecba59bc33 ("e1000e: Do not read ICR in Other interrupt") Signed-off-by: Benjamin Poirier <bpoirier(a)suse.com> Tested-by: Aaron Brown <aaron.f.brown(a)intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher(a)intel.com> Signed-off-by: Amit Pundir <amit.pundir(a)linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/intel/e1000e/defines.h | 1 drivers/net/ethernet/intel/e1000e/netdev.c | 31 +++++++++++++++++++++------- 2 files changed, 25 insertions(+), 7 deletions(-) --- a/drivers/net/ethernet/intel/e1000e/defines.h +++ b/drivers/net/ethernet/intel/e1000e/defines.h @@ -398,6 +398,7 @@ #define E1000_ICR_LSC 0x00000004 /* Link Status Change */ #define E1000_ICR_RXSEQ 0x00000008 /* Rx sequence error */ #define E1000_ICR_RXDMT0 0x00000010 /* Rx desc min. threshold (0) */ +#define E1000_ICR_RXO 0x00000040 /* Receiver Overrun */ #define E1000_ICR_RXT0 0x00000080 /* Rx timer intr (ring 0) */ #define E1000_ICR_ECCER 0x00400000 /* Uncorrectable ECC Error */ /* If this bit asserted, the driver should claim the interrupt */ --- a/drivers/net/ethernet/intel/e1000e/netdev.c +++ b/drivers/net/ethernet/intel/e1000e/netdev.c @@ -1905,14 +1905,30 @@ static irqreturn_t e1000_msix_other(int struct net_device *netdev = data; struct e1000_adapter *adapter = netdev_priv(netdev); struct e1000_hw *hw = &adapter->hw; + u32 icr; + bool enable = true; - hw->mac.get_link_status = true; + icr = er32(ICR); + if (icr & E1000_ICR_RXO) { + ew32(ICR, E1000_ICR_RXO); + enable = false; + /* napi poll will re-enable Other, make sure it runs */ + if (napi_schedule_prep(&adapter->napi)) { + adapter->total_rx_bytes = 0; + adapter->total_rx_packets = 0; + __napi_schedule(&adapter->napi); + } + } + if (icr & E1000_ICR_LSC) { + ew32(ICR, E1000_ICR_LSC); + hw->mac.get_link_status = true; + /* guard against interrupt when we're going down */ + if (!test_bit(__E1000_DOWN, &adapter->state)) + mod_timer(&adapter->watchdog_timer, jiffies + 1); + } - /* guard against interrupt when we're going down */ - if (!test_bit(__E1000_DOWN, &adapter->state)) { - mod_timer(&adapter->watchdog_timer, jiffies + 1); + if (enable && !test_bit(__E1000_DOWN, &adapter->state)) ew32(IMS, E1000_IMS_OTHER); - } return IRQ_HANDLED; } @@ -2683,7 +2699,8 @@ static int e1000e_poll(struct napi_struc napi_complete_done(napi, work_done); if (!test_bit(__E1000_DOWN, &adapter->state)) { if (adapter->msix_entries) - ew32(IMS, adapter->rx_ring->ims_val); + ew32(IMS, adapter->rx_ring->ims_val | + E1000_IMS_OTHER); else e1000_irq_enable(adapter); } @@ -4178,7 +4195,7 @@ static void e1000e_trigger_lsc(struct e1 struct e1000_hw *hw = &adapter->hw; if (adapter->msix_entries) - ew32(ICS, E1000_ICS_OTHER); + ew32(ICS, E1000_ICS_LSC | E1000_ICS_OTHER); else ew32(ICS, E1000_ICS_LSC); } Patches currently in stable-queue which might be from bpoirier(a)suse.com are queue-4.9/e1000e-fix-error-path-in-link-detection.patch queue-4.9/e1000e-separate-signaling-for-link-check-link-up.patch queue-4.9/e1000e-fix-return-value-test.patch queue-4.9/e1000e-avoid-receiver-overrun-interrupt-bursts.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "e1000e: Separate signaling for link check/link up" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled e1000e: Separate signaling for link check/link up to the 4.4-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: e1000e-separate-signaling-for-link-check-link-up.patch and it can be found in the queue-4.4 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 19110cfbb34d4af0cdfe14cd243f3b09dc95b013 Mon Sep 17 00:00:00 2001 From: Benjamin Poirier <bpoirier(a)suse.com> Date: Fri, 21 Jul 2017 11:36:26 -0700 Subject: e1000e: Separate signaling for link check/link up From: Benjamin Poirier <bpoirier(a)suse.com> commit 19110cfbb34d4af0cdfe14cd243f3b09dc95b013 upstream. Lennart reported the following race condition: \ e1000_watchdog_task \ e1000e_has_link \ hw->mac.ops.check_for_link() === e1000e_check_for_copper_link /* link is up */ mac->get_link_status = false; /* interrupt */ \ e1000_msix_other hw->mac.get_link_status = true; link_active = !hw->mac.get_link_status /* link_active is false, wrongly */ This problem arises because the single flag get_link_status is used to signal two different states: link status needs checking and link status is down. Avoid the problem by using the return value of .check_for_link to signal the link status to e1000e_has_link(). Reported-by: Lennart Sorensen <lsorense(a)csclub.uwaterloo.ca> Signed-off-by: Benjamin Poirier <bpoirier(a)suse.com> Tested-by: Aaron Brown <aaron.f.brown(a)intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher(a)intel.com> Signed-off-by: Amit Pundir <amit.pundir(a)linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/intel/e1000e/mac.c | 11 ++++++++--- drivers/net/ethernet/intel/e1000e/netdev.c | 2 +- 2 files changed, 9 insertions(+), 4 deletions(-) --- a/drivers/net/ethernet/intel/e1000e/mac.c +++ b/drivers/net/ethernet/intel/e1000e/mac.c @@ -410,6 +410,9 @@ void e1000e_clear_hw_cntrs_base(struct e * Checks to see of the link status of the hardware has changed. If a * change in link status has been detected, then we read the PHY registers * to get the current speed/duplex if link exists. + * + * Returns a negative error code (-E1000_ERR_*) or 0 (link down) or 1 (link + * up). **/ s32 e1000e_check_for_copper_link(struct e1000_hw *hw) { @@ -423,7 +426,7 @@ s32 e1000e_check_for_copper_link(struct * Change or Rx Sequence Error interrupt. */ if (!mac->get_link_status) - return 0; + return 1; /* First we want to see if the MII Status Register reports * link. If so, then we want to get the current speed/duplex @@ -461,10 +464,12 @@ s32 e1000e_check_for_copper_link(struct * different link partner. */ ret_val = e1000e_config_fc_after_link_up(hw); - if (ret_val) + if (ret_val) { e_dbg("Error configuring flow control\n"); + return ret_val; + } - return ret_val; + return 1; } /** --- a/drivers/net/ethernet/intel/e1000e/netdev.c +++ b/drivers/net/ethernet/intel/e1000e/netdev.c @@ -5017,7 +5017,7 @@ static bool e1000e_has_link(struct e1000 case e1000_media_type_copper: if (hw->mac.get_link_status) { ret_val = hw->mac.ops.check_for_link(hw); - link_active = !hw->mac.get_link_status; + link_active = ret_val > 0; } else { link_active = true; } Patches currently in stable-queue which might be from bpoirier(a)suse.com are queue-4.4/e1000e-fix-error-path-in-link-detection.patch queue-4.4/e1000e-separate-signaling-for-link-check-link-up.patch queue-4.4/e1000e-fix-return-value-test.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "e1000e: Fix return value test" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled e1000e: Fix return value test to the 4.4-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: e1000e-fix-return-value-test.patch and it can be found in the queue-4.4 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 d3509f8bc7b0560044c15f0e3ecfde1d9af757a6 Mon Sep 17 00:00:00 2001 From: Benjamin Poirier <bpoirier(a)suse.com> Date: Fri, 21 Jul 2017 11:36:25 -0700 Subject: e1000e: Fix return value test From: Benjamin Poirier <bpoirier(a)suse.com> commit d3509f8bc7b0560044c15f0e3ecfde1d9af757a6 upstream. All the helpers return -E1000_ERR_PHY. Signed-off-by: Benjamin Poirier <bpoirier(a)suse.com> Tested-by: Aaron Brown <aaron.f.brown(a)intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher(a)intel.com> Signed-off-by: Amit Pundir <amit.pundir(a)linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/intel/e1000e/netdev.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/net/ethernet/intel/e1000e/netdev.c +++ b/drivers/net/ethernet/intel/e1000e/netdev.c @@ -5035,7 +5035,7 @@ static bool e1000e_has_link(struct e1000 break; } - if ((ret_val == E1000_ERR_PHY) && (hw->phy.type == e1000_phy_igp_3) && + if ((ret_val == -E1000_ERR_PHY) && (hw->phy.type == e1000_phy_igp_3) && (er32(CTRL) & E1000_PHY_CTRL_GBE_DISABLE)) { /* See e1000_kmrn_lock_loss_workaround_ich8lan() */ e_info("Gigabit has been disabled, downgrading speed\n"); Patches currently in stable-queue which might be from bpoirier(a)suse.com are queue-4.4/e1000e-fix-error-path-in-link-detection.patch queue-4.4/e1000e-separate-signaling-for-link-check-link-up.patch queue-4.4/e1000e-fix-return-value-test.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "e1000e: Fix error path in link detection" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled e1000e: Fix error path in link detection to the 4.4-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: e1000e-fix-error-path-in-link-detection.patch and it can be found in the queue-4.4 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 c4c40e51f9c32c6dd8adf606624c930a1c4d9bbb Mon Sep 17 00:00:00 2001 From: Benjamin Poirier <bpoirier(a)suse.com> Date: Fri, 21 Jul 2017 11:36:23 -0700 Subject: e1000e: Fix error path in link detection From: Benjamin Poirier <bpoirier(a)suse.com> commit c4c40e51f9c32c6dd8adf606624c930a1c4d9bbb upstream. In case of error from e1e_rphy(), the loop will exit early and "success" will be set to true erroneously. Signed-off-by: Benjamin Poirier <bpoirier(a)suse.com> Tested-by: Aaron Brown <aaron.f.brown(a)intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher(a)intel.com> Signed-off-by: Amit Pundir <amit.pundir(a)linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/intel/e1000e/phy.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) --- a/drivers/net/ethernet/intel/e1000e/phy.c +++ b/drivers/net/ethernet/intel/e1000e/phy.c @@ -1744,6 +1744,7 @@ s32 e1000e_phy_has_link_generic(struct e s32 ret_val = 0; u16 i, phy_status; + *success = false; for (i = 0; i < iterations; i++) { /* Some PHYs require the MII_BMSR register to be read * twice due to the link bit being sticky. No harm doing @@ -1763,16 +1764,16 @@ s32 e1000e_phy_has_link_generic(struct e ret_val = e1e_rphy(hw, MII_BMSR, &phy_status); if (ret_val) break; - if (phy_status & BMSR_LSTATUS) + if (phy_status & BMSR_LSTATUS) { + *success = true; break; + } if (usec_interval >= 1000) msleep(usec_interval / 1000); else udelay(usec_interval); } - *success = (i < iterations); - return ret_val; } Patches currently in stable-queue which might be from bpoirier(a)suse.com are queue-4.4/e1000e-fix-error-path-in-link-detection.patch queue-4.4/e1000e-separate-signaling-for-link-check-link-up.patch queue-4.4/e1000e-fix-return-value-test.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "e1000e: Separate signaling for link check/link up" 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 e1000e: Separate signaling for link check/link up 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: e1000e-separate-signaling-for-link-check-link-up.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 19110cfbb34d4af0cdfe14cd243f3b09dc95b013 Mon Sep 17 00:00:00 2001 From: Benjamin Poirier <bpoirier(a)suse.com> Date: Fri, 21 Jul 2017 11:36:26 -0700 Subject: e1000e: Separate signaling for link check/link up From: Benjamin Poirier <bpoirier(a)suse.com> commit 19110cfbb34d4af0cdfe14cd243f3b09dc95b013 upstream. Lennart reported the following race condition: \ e1000_watchdog_task \ e1000e_has_link \ hw->mac.ops.check_for_link() === e1000e_check_for_copper_link /* link is up */ mac->get_link_status = false; /* interrupt */ \ e1000_msix_other hw->mac.get_link_status = true; link_active = !hw->mac.get_link_status /* link_active is false, wrongly */ This problem arises because the single flag get_link_status is used to signal two different states: link status needs checking and link status is down. Avoid the problem by using the return value of .check_for_link to signal the link status to e1000e_has_link(). Reported-by: Lennart Sorensen <lsorense(a)csclub.uwaterloo.ca> Signed-off-by: Benjamin Poirier <bpoirier(a)suse.com> Tested-by: Aaron Brown <aaron.f.brown(a)intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher(a)intel.com> Signed-off-by: Amit Pundir <amit.pundir(a)linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/intel/e1000e/mac.c | 11 ++++++++--- drivers/net/ethernet/intel/e1000e/netdev.c | 2 +- 2 files changed, 9 insertions(+), 4 deletions(-) --- a/drivers/net/ethernet/intel/e1000e/mac.c +++ b/drivers/net/ethernet/intel/e1000e/mac.c @@ -410,6 +410,9 @@ void e1000e_clear_hw_cntrs_base(struct e * Checks to see of the link status of the hardware has changed. If a * change in link status has been detected, then we read the PHY registers * to get the current speed/duplex if link exists. + * + * Returns a negative error code (-E1000_ERR_*) or 0 (link down) or 1 (link + * up). **/ s32 e1000e_check_for_copper_link(struct e1000_hw *hw) { @@ -423,7 +426,7 @@ s32 e1000e_check_for_copper_link(struct * Change or Rx Sequence Error interrupt. */ if (!mac->get_link_status) - return 0; + return 1; /* First we want to see if the MII Status Register reports * link. If so, then we want to get the current speed/duplex @@ -461,10 +464,12 @@ s32 e1000e_check_for_copper_link(struct * different link partner. */ ret_val = e1000e_config_fc_after_link_up(hw); - if (ret_val) + if (ret_val) { e_dbg("Error configuring flow control\n"); + return ret_val; + } - return ret_val; + return 1; } /** --- a/drivers/net/ethernet/intel/e1000e/netdev.c +++ b/drivers/net/ethernet/intel/e1000e/netdev.c @@ -5081,7 +5081,7 @@ static bool e1000e_has_link(struct e1000 case e1000_media_type_copper: if (hw->mac.get_link_status) { ret_val = hw->mac.ops.check_for_link(hw); - link_active = !hw->mac.get_link_status; + link_active = ret_val > 0; } else { link_active = true; } Patches currently in stable-queue which might be from bpoirier(a)suse.com are queue-4.14/e1000e-fix-error-path-in-link-detection.patch queue-4.14/e1000e-separate-signaling-for-link-check-link-up.patch queue-4.14/e1000e-fix-return-value-test.patch queue-4.14/e1000e-avoid-receiver-overrun-interrupt-bursts.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "e1000e: Fix return value test" 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 e1000e: Fix return value test 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: e1000e-fix-return-value-test.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 d3509f8bc7b0560044c15f0e3ecfde1d9af757a6 Mon Sep 17 00:00:00 2001 From: Benjamin Poirier <bpoirier(a)suse.com> Date: Fri, 21 Jul 2017 11:36:25 -0700 Subject: e1000e: Fix return value test From: Benjamin Poirier <bpoirier(a)suse.com> commit d3509f8bc7b0560044c15f0e3ecfde1d9af757a6 upstream. All the helpers return -E1000_ERR_PHY. Signed-off-by: Benjamin Poirier <bpoirier(a)suse.com> Tested-by: Aaron Brown <aaron.f.brown(a)intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher(a)intel.com> Signed-off-by: Amit Pundir <amit.pundir(a)linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/intel/e1000e/netdev.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/net/ethernet/intel/e1000e/netdev.c +++ b/drivers/net/ethernet/intel/e1000e/netdev.c @@ -5099,7 +5099,7 @@ static bool e1000e_has_link(struct e1000 break; } - if ((ret_val == E1000_ERR_PHY) && (hw->phy.type == e1000_phy_igp_3) && + if ((ret_val == -E1000_ERR_PHY) && (hw->phy.type == e1000_phy_igp_3) && (er32(CTRL) & E1000_PHY_CTRL_GBE_DISABLE)) { /* See e1000_kmrn_lock_loss_workaround_ich8lan() */ e_info("Gigabit has been disabled, downgrading speed\n"); Patches currently in stable-queue which might be from bpoirier(a)suse.com are queue-4.14/e1000e-fix-error-path-in-link-detection.patch queue-4.14/e1000e-separate-signaling-for-link-check-link-up.patch queue-4.14/e1000e-fix-return-value-test.patch queue-4.14/e1000e-avoid-receiver-overrun-interrupt-bursts.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "e1000e: Fix error path in link detection" 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 e1000e: Fix error path in link detection 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: e1000e-fix-error-path-in-link-detection.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 c4c40e51f9c32c6dd8adf606624c930a1c4d9bbb Mon Sep 17 00:00:00 2001 From: Benjamin Poirier <bpoirier(a)suse.com> Date: Fri, 21 Jul 2017 11:36:23 -0700 Subject: e1000e: Fix error path in link detection From: Benjamin Poirier <bpoirier(a)suse.com> commit c4c40e51f9c32c6dd8adf606624c930a1c4d9bbb upstream. In case of error from e1e_rphy(), the loop will exit early and "success" will be set to true erroneously. Signed-off-by: Benjamin Poirier <bpoirier(a)suse.com> Tested-by: Aaron Brown <aaron.f.brown(a)intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher(a)intel.com> Signed-off-by: Amit Pundir <amit.pundir(a)linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/intel/e1000e/phy.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) --- a/drivers/net/ethernet/intel/e1000e/phy.c +++ b/drivers/net/ethernet/intel/e1000e/phy.c @@ -1744,6 +1744,7 @@ s32 e1000e_phy_has_link_generic(struct e s32 ret_val = 0; u16 i, phy_status; + *success = false; for (i = 0; i < iterations; i++) { /* Some PHYs require the MII_BMSR register to be read * twice due to the link bit being sticky. No harm doing @@ -1763,16 +1764,16 @@ s32 e1000e_phy_has_link_generic(struct e ret_val = e1e_rphy(hw, MII_BMSR, &phy_status); if (ret_val) break; - if (phy_status & BMSR_LSTATUS) + if (phy_status & BMSR_LSTATUS) { + *success = true; break; + } if (usec_interval >= 1000) msleep(usec_interval / 1000); else udelay(usec_interval); } - *success = (i < iterations); - return ret_val; } Patches currently in stable-queue which might be from bpoirier(a)suse.com are queue-4.14/e1000e-fix-error-path-in-link-detection.patch queue-4.14/e1000e-separate-signaling-for-link-check-link-up.patch queue-4.14/e1000e-fix-return-value-test.patch queue-4.14/e1000e-avoid-receiver-overrun-interrupt-bursts.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "e1000e: Avoid receiver overrun interrupt bursts" 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 e1000e: Avoid receiver overrun interrupt bursts 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: e1000e-avoid-receiver-overrun-interrupt-bursts.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 4aea7a5c5e940c1723add439f4088844cd26196d Mon Sep 17 00:00:00 2001 From: Benjamin Poirier <bpoirier(a)suse.com> Date: Fri, 21 Jul 2017 11:36:27 -0700 Subject: e1000e: Avoid receiver overrun interrupt bursts From: Benjamin Poirier <bpoirier(a)suse.com> commit 4aea7a5c5e940c1723add439f4088844cd26196d upstream. When e1000e_poll() is not fast enough to keep up with incoming traffic, the adapter (when operating in msix mode) raises the Other interrupt to signal Receiver Overrun. This is a double problem because 1) at the moment e1000_msix_other() assumes that it is only called in case of Link Status Change and 2) if the condition persists, the interrupt is repeatedly raised again in quick succession. Ideally we would configure the Other interrupt to not be raised in case of receiver overrun but this doesn't seem possible on this adapter. Instead, we handle the first part of the problem by reverting to the practice of reading ICR in the other interrupt handler, like before commit 16ecba59bc33 ("e1000e: Do not read ICR in Other interrupt"). Thanks to commit 0a8047ac68e5 ("e1000e: Fix msi-x interrupt automask") which cleared IAME from CTRL_EXT, reading ICR doesn't interfere with RxQ0, TxQ0 interrupts anymore. We handle the second part of the problem by not re-enabling the Other interrupt right away when there is overrun. Instead, we wait until traffic subsides, napi polling mode is exited and interrupts are re-enabled. Reported-by: Lennart Sorensen <lsorense(a)csclub.uwaterloo.ca> Fixes: 16ecba59bc33 ("e1000e: Do not read ICR in Other interrupt") Signed-off-by: Benjamin Poirier <bpoirier(a)suse.com> Tested-by: Aaron Brown <aaron.f.brown(a)intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher(a)intel.com> Signed-off-by: Amit Pundir <amit.pundir(a)linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/intel/e1000e/defines.h | 1 drivers/net/ethernet/intel/e1000e/netdev.c | 31 +++++++++++++++++++++------- 2 files changed, 25 insertions(+), 7 deletions(-) --- a/drivers/net/ethernet/intel/e1000e/defines.h +++ b/drivers/net/ethernet/intel/e1000e/defines.h @@ -398,6 +398,7 @@ #define E1000_ICR_LSC 0x00000004 /* Link Status Change */ #define E1000_ICR_RXSEQ 0x00000008 /* Rx sequence error */ #define E1000_ICR_RXDMT0 0x00000010 /* Rx desc min. threshold (0) */ +#define E1000_ICR_RXO 0x00000040 /* Receiver Overrun */ #define E1000_ICR_RXT0 0x00000080 /* Rx timer intr (ring 0) */ #define E1000_ICR_ECCER 0x00400000 /* Uncorrectable ECC Error */ /* If this bit asserted, the driver should claim the interrupt */ --- a/drivers/net/ethernet/intel/e1000e/netdev.c +++ b/drivers/net/ethernet/intel/e1000e/netdev.c @@ -1910,14 +1910,30 @@ static irqreturn_t e1000_msix_other(int struct net_device *netdev = data; struct e1000_adapter *adapter = netdev_priv(netdev); struct e1000_hw *hw = &adapter->hw; + u32 icr; + bool enable = true; - hw->mac.get_link_status = true; + icr = er32(ICR); + if (icr & E1000_ICR_RXO) { + ew32(ICR, E1000_ICR_RXO); + enable = false; + /* napi poll will re-enable Other, make sure it runs */ + if (napi_schedule_prep(&adapter->napi)) { + adapter->total_rx_bytes = 0; + adapter->total_rx_packets = 0; + __napi_schedule(&adapter->napi); + } + } + if (icr & E1000_ICR_LSC) { + ew32(ICR, E1000_ICR_LSC); + hw->mac.get_link_status = true; + /* guard against interrupt when we're going down */ + if (!test_bit(__E1000_DOWN, &adapter->state)) + mod_timer(&adapter->watchdog_timer, jiffies + 1); + } - /* guard against interrupt when we're going down */ - if (!test_bit(__E1000_DOWN, &adapter->state)) { - mod_timer(&adapter->watchdog_timer, jiffies + 1); + if (enable && !test_bit(__E1000_DOWN, &adapter->state)) ew32(IMS, E1000_IMS_OTHER); - } return IRQ_HANDLED; } @@ -2687,7 +2703,8 @@ static int e1000e_poll(struct napi_struc napi_complete_done(napi, work_done); if (!test_bit(__E1000_DOWN, &adapter->state)) { if (adapter->msix_entries) - ew32(IMS, adapter->rx_ring->ims_val); + ew32(IMS, adapter->rx_ring->ims_val | + E1000_IMS_OTHER); else e1000_irq_enable(adapter); } @@ -4204,7 +4221,7 @@ static void e1000e_trigger_lsc(struct e1 struct e1000_hw *hw = &adapter->hw; if (adapter->msix_entries) - ew32(ICS, E1000_ICS_OTHER); + ew32(ICS, E1000_ICS_LSC | E1000_ICS_OTHER); else ew32(ICS, E1000_ICS_LSC); } Patches currently in stable-queue which might be from bpoirier(a)suse.com are queue-4.14/e1000e-fix-error-path-in-link-detection.patch queue-4.14/e1000e-separate-signaling-for-link-check-link-up.patch queue-4.14/e1000e-fix-return-value-test.patch queue-4.14/e1000e-avoid-receiver-overrun-interrupt-bursts.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "USB: fix buffer overflows with parsing CDC headers" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled USB: fix buffer overflows with parsing CDC headers to the 3.18-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: usb-fix-buffer-overflows-with-parsing-cdc-headers.patch and it can be found in the queue-3.18 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 oneukum(a)suse.com Tue Nov 28 10:13:45 2017 From: Oliver Neukum <oneukum(a)suse.com> Date: Thu, 23 Nov 2017 16:20:05 +0100 Subject: USB: fix buffer overflows with parsing CDC headers To: gregKH(a)linuxfoundation.org, linux-usb(a)vger.kernel.org, stable(a)kernel.org Cc: Oliver Neukum <oneukum(a)suse.com> Message-ID: <20171123152005.22493-1-oneukum(a)suse.com> From: Oliver Neukum <oneukum(a)suse.com> Parsing CDC headers a buffer overflow cannot just be prevented by checking that the remainder of the buffer is longer than minimum length. The size of the fields to be parsed must be figured in, too. In newer kernels this issue has been fixed at a central location with commit 2e1c42391ff2556387b3cb6308b24f6f65619feb Author: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Date: Thu Sep 21 16:58:48 2017 +0200 USB: core: harden cdc_parse_cdc_header on anything older the parsing had not been centralised, so a separate fix for each driver is necessary. Signed-off-by: Oliver Neukum <oneukum(a)suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/usb/cdc_ether.c | 9 ++++++++- drivers/usb/class/cdc-acm.c | 2 +- drivers/usb/class/cdc-wdm.c | 2 ++ 3 files changed, 11 insertions(+), 2 deletions(-) --- a/drivers/net/usb/cdc_ether.c +++ b/drivers/net/usb/cdc_ether.c @@ -171,6 +171,8 @@ int usbnet_generic_cdc_bind(struct usbne dev_dbg(&intf->dev, "extra CDC header\n"); goto bad_desc; } + if (len < sizeof(struct usb_cdc_header_desc)) + break; info->header = (void *) buf; if (info->header->bLength != sizeof(*info->header)) { dev_dbg(&intf->dev, "CDC header len %u\n", @@ -184,6 +186,8 @@ int usbnet_generic_cdc_bind(struct usbne */ if (rndis) { struct usb_cdc_acm_descriptor *acm; + if (len < sizeof(struct usb_cdc_acm_descriptor)) + break; acm = (void *) buf; if (acm->bmCapabilities) { @@ -200,6 +204,8 @@ int usbnet_generic_cdc_bind(struct usbne dev_dbg(&intf->dev, "extra CDC union\n"); goto bad_desc; } + if (len < sizeof(struct usb_cdc_union_desc)) + break; info->u = (void *) buf; if (info->u->bLength != sizeof(*info->u)) { dev_dbg(&intf->dev, "CDC union len %u\n", @@ -258,6 +264,8 @@ int usbnet_generic_cdc_bind(struct usbne dev_dbg(&intf->dev, "extra CDC ether\n"); goto bad_desc; } + if (len < sizeof(struct usb_cdc_ether_desc)) + break; info->ether = (void *) buf; if (info->ether->bLength != sizeof(*info->ether)) { dev_dbg(&intf->dev, "CDC ether len %u\n", @@ -275,7 +283,6 @@ int usbnet_generic_cdc_bind(struct usbne dev_dbg(&intf->dev, "extra MDLM descriptor\n"); goto bad_desc; } - desc = (void *)buf; if (desc->bLength != sizeof(*desc)) --- a/drivers/usb/class/cdc-acm.c +++ b/drivers/usb/class/cdc-acm.c @@ -1139,7 +1139,7 @@ static int acm_probe(struct usb_interfac } } - while (buflen > 0) { + while (buflen >= 3) { /* minimum length making sense */ elength = buffer[0]; if (!elength) { dev_err(&intf->dev, "skipping garbage byte\n"); --- a/drivers/usb/class/cdc-wdm.c +++ b/drivers/usb/class/cdc-wdm.c @@ -891,6 +891,8 @@ static int wdm_probe(struct usb_interfac case USB_CDC_HEADER_TYPE: break; case USB_CDC_DMM_TYPE: + if (buflen < sizeof(struct usb_cdc_dmm_desc)) + break; dmhd = (struct usb_cdc_dmm_desc *)buffer; maxcom = le16_to_cpu(dmhd->wMaxCommand); dev_dbg(&intf->dev, Patches currently in stable-queue which might be from oneukum(a)suse.com are queue-3.18/usb-fix-buffer-overflows-with-parsing-cdc-headers.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] [PATCH 3.16-4.4] iio: iio-trig-periodic-rtc: Free trigger resource correctly

by Ben Hutchings

This is based on upstream commit 10e840dfb0b7, which did not touch the iio-trig-periodic-rtc driver because it has been removed upstream. The following explanation comes from that commit: These stand-alone trigger drivers were using iio_trigger_put() where they should have been using iio_trigger_free(). The iio_trigger_put() adds a module_put which is bad since they never did a module_get. In the sysfs driver, module_get/put's are used as triggers are added & removed. This extra module_put() occurs on an error path in the probe routine (probably rare). In the bfin-timer & interrupt trigger drivers, the module resources are not explicitly managed, so it's doing a put on something that was never get'd. It occurs on the probe error path and on the remove path (not so rare). Tested with the sysfs trigger driver. The bfin & interrupt drivers were build tested & inspected only. This was build tested only. Cc: Alison Schofield <amsfield22(a)gmail.com> Cc: Jonathan Cameron <jic23(a)kernel.org> Signed-off-by: Ben Hutchings <ben.hutchings(a)codethink.co.uk> --- drivers/staging/iio/trigger/iio-trig-periodic-rtc.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/staging/iio/trigger/iio-trig-periodic-rtc.c b/drivers/staging/iio/trigger/iio-trig-periodic-rtc.c index 00d139331261..52430e57e346 100644 --- a/drivers/staging/iio/trigger/iio-trig-periodic-rtc.c +++ b/drivers/staging/iio/trigger/iio-trig-periodic-rtc.c @@ -137,7 +137,7 @@ static int iio_trig_periodic_rtc_probe(struct platform_device *dev) trig_info = kzalloc(sizeof(*trig_info), GFP_KERNEL); if (!trig_info) { ret = -ENOMEM; - goto error_put_trigger_and_remove_from_list; + goto error_free_trigger_and_remove_from_list; } iio_trigger_set_drvdata(trig, trig_info); trig->ops = &iio_prtc_trigger_ops; @@ -164,9 +164,9 @@ error_close_rtc: rtc_class_close(trig_info->rtc); error_free_trig_info: kfree(trig_info); -error_put_trigger_and_remove_from_list: +error_free_trigger_and_remove_from_list: list_del(&trig->alloc_list); - iio_trigger_put(trig); + iio_trigger_free(trig); error_free_completed_registrations: list_for_each_entry_safe(trig, trig2, -- 2.15.0.rc0

7 years, 5 months

3
2
0 0

[Linux-stable-mirror] Patch "e1000e: Separate signaling for link check/link up" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled e1000e: Separate signaling for link check/link up to the 3.18-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: e1000e-separate-signaling-for-link-check-link-up.patch and it can be found in the queue-3.18 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 19110cfbb34d4af0cdfe14cd243f3b09dc95b013 Mon Sep 17 00:00:00 2001 From: Benjamin Poirier <bpoirier(a)suse.com> Date: Fri, 21 Jul 2017 11:36:26 -0700 Subject: e1000e: Separate signaling for link check/link up From: Benjamin Poirier <bpoirier(a)suse.com> commit 19110cfbb34d4af0cdfe14cd243f3b09dc95b013 upstream. Lennart reported the following race condition: \ e1000_watchdog_task \ e1000e_has_link \ hw->mac.ops.check_for_link() === e1000e_check_for_copper_link /* link is up */ mac->get_link_status = false; /* interrupt */ \ e1000_msix_other hw->mac.get_link_status = true; link_active = !hw->mac.get_link_status /* link_active is false, wrongly */ This problem arises because the single flag get_link_status is used to signal two different states: link status needs checking and link status is down. Avoid the problem by using the return value of .check_for_link to signal the link status to e1000e_has_link(). Reported-by: Lennart Sorensen <lsorense(a)csclub.uwaterloo.ca> Signed-off-by: Benjamin Poirier <bpoirier(a)suse.com> Tested-by: Aaron Brown <aaron.f.brown(a)intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher(a)intel.com> Signed-off-by: Amit Pundir <amit.pundir(a)linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/intel/e1000e/mac.c | 11 ++++++++--- drivers/net/ethernet/intel/e1000e/netdev.c | 2 +- 2 files changed, 9 insertions(+), 4 deletions(-) --- a/drivers/net/ethernet/intel/e1000e/mac.c +++ b/drivers/net/ethernet/intel/e1000e/mac.c @@ -410,6 +410,9 @@ void e1000e_clear_hw_cntrs_base(struct e * Checks to see of the link status of the hardware has changed. If a * change in link status has been detected, then we read the PHY registers * to get the current speed/duplex if link exists. + * + * Returns a negative error code (-E1000_ERR_*) or 0 (link down) or 1 (link + * up). **/ s32 e1000e_check_for_copper_link(struct e1000_hw *hw) { @@ -423,7 +426,7 @@ s32 e1000e_check_for_copper_link(struct * Change or Rx Sequence Error interrupt. */ if (!mac->get_link_status) - return 0; + return 1; /* First we want to see if the MII Status Register reports * link. If so, then we want to get the current speed/duplex @@ -461,10 +464,12 @@ s32 e1000e_check_for_copper_link(struct * different link partner. */ ret_val = e1000e_config_fc_after_link_up(hw); - if (ret_val) + if (ret_val) { e_dbg("Error configuring flow control\n"); + return ret_val; + } - return ret_val; + return 1; } /** --- a/drivers/net/ethernet/intel/e1000e/netdev.c +++ b/drivers/net/ethernet/intel/e1000e/netdev.c @@ -4844,7 +4844,7 @@ static bool e1000e_has_link(struct e1000 case e1000_media_type_copper: if (hw->mac.get_link_status) { ret_val = hw->mac.ops.check_for_link(hw); - link_active = !hw->mac.get_link_status; + link_active = ret_val > 0; } else { link_active = true; } Patches currently in stable-queue which might be from bpoirier(a)suse.com are queue-3.18/e1000e-fix-error-path-in-link-detection.patch queue-3.18/e1000e-separate-signaling-for-link-check-link-up.patch queue-3.18/e1000e-fix-return-value-test.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "e1000e: Fix return value test" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled e1000e: Fix return value test to the 3.18-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: e1000e-fix-return-value-test.patch and it can be found in the queue-3.18 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 d3509f8bc7b0560044c15f0e3ecfde1d9af757a6 Mon Sep 17 00:00:00 2001 From: Benjamin Poirier <bpoirier(a)suse.com> Date: Fri, 21 Jul 2017 11:36:25 -0700 Subject: e1000e: Fix return value test From: Benjamin Poirier <bpoirier(a)suse.com> commit d3509f8bc7b0560044c15f0e3ecfde1d9af757a6 upstream. All the helpers return -E1000_ERR_PHY. Signed-off-by: Benjamin Poirier <bpoirier(a)suse.com> Tested-by: Aaron Brown <aaron.f.brown(a)intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher(a)intel.com> Signed-off-by: Amit Pundir <amit.pundir(a)linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/intel/e1000e/netdev.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/net/ethernet/intel/e1000e/netdev.c +++ b/drivers/net/ethernet/intel/e1000e/netdev.c @@ -4862,7 +4862,7 @@ static bool e1000e_has_link(struct e1000 break; } - if ((ret_val == E1000_ERR_PHY) && (hw->phy.type == e1000_phy_igp_3) && + if ((ret_val == -E1000_ERR_PHY) && (hw->phy.type == e1000_phy_igp_3) && (er32(CTRL) & E1000_PHY_CTRL_GBE_DISABLE)) { /* See e1000_kmrn_lock_loss_workaround_ich8lan() */ e_info("Gigabit has been disabled, downgrading speed\n"); Patches currently in stable-queue which might be from bpoirier(a)suse.com are queue-3.18/e1000e-fix-error-path-in-link-detection.patch queue-3.18/e1000e-separate-signaling-for-link-check-link-up.patch queue-3.18/e1000e-fix-return-value-test.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "e1000e: Fix error path in link detection" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled e1000e: Fix error path in link detection to the 3.18-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: e1000e-fix-error-path-in-link-detection.patch and it can be found in the queue-3.18 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 c4c40e51f9c32c6dd8adf606624c930a1c4d9bbb Mon Sep 17 00:00:00 2001 From: Benjamin Poirier <bpoirier(a)suse.com> Date: Fri, 21 Jul 2017 11:36:23 -0700 Subject: e1000e: Fix error path in link detection From: Benjamin Poirier <bpoirier(a)suse.com> commit c4c40e51f9c32c6dd8adf606624c930a1c4d9bbb upstream. In case of error from e1e_rphy(), the loop will exit early and "success" will be set to true erroneously. Signed-off-by: Benjamin Poirier <bpoirier(a)suse.com> Tested-by: Aaron Brown <aaron.f.brown(a)intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher(a)intel.com> Signed-off-by: Amit Pundir <amit.pundir(a)linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/intel/e1000e/phy.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) --- a/drivers/net/ethernet/intel/e1000e/phy.c +++ b/drivers/net/ethernet/intel/e1000e/phy.c @@ -1744,6 +1744,7 @@ s32 e1000e_phy_has_link_generic(struct e s32 ret_val = 0; u16 i, phy_status; + *success = false; for (i = 0; i < iterations; i++) { /* Some PHYs require the MII_BMSR register to be read * twice due to the link bit being sticky. No harm doing @@ -1763,16 +1764,16 @@ s32 e1000e_phy_has_link_generic(struct e ret_val = e1e_rphy(hw, MII_BMSR, &phy_status); if (ret_val) break; - if (phy_status & BMSR_LSTATUS) + if (phy_status & BMSR_LSTATUS) { + *success = true; break; + } if (usec_interval >= 1000) msleep(usec_interval / 1000); else udelay(usec_interval); } - *success = (i < iterations); - return ret_val; } Patches currently in stable-queue which might be from bpoirier(a)suse.com are queue-3.18/e1000e-fix-error-path-in-link-detection.patch queue-3.18/e1000e-separate-signaling-for-link-check-link-up.patch queue-3.18/e1000e-fix-return-value-test.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] [PATCH for-4.14.y 0/5] e1000e: Upstream fixes for linux-4.14.y

by Amit Pundir

Hi Greg, Found few e100e upstream fixes from Benjamin Poirier in lede source tree, https://git.lede-project.org/?p=source.git, and these fixes seem reasonable enough for 4.14.y too. Also submitting an e1000e buffer overrun fix by Sasha Neftin. Cherry-picked and build tested for linux v4.14.2 for ARCH=arm/arm64. Regards, Amit Pundir Benjamin Poirier (4): e1000e: Fix error path in link detection e1000e: Fix return value test e1000e: Separate signaling for link check/link up e1000e: Avoid receiver overrun interrupt bursts Sasha Neftin (1): e1000e: fix buffer overrun while the I219 is processing DMA transactions drivers/net/ethernet/intel/e1000e/defines.h | 1 + drivers/net/ethernet/intel/e1000e/mac.c | 11 +++++-- drivers/net/ethernet/intel/e1000e/netdev.c | 45 ++++++++++++++++++++--------- drivers/net/ethernet/intel/e1000e/phy.c | 7 +++-- 4 files changed, 45 insertions(+), 19 deletions(-) -- 2.7.4

7 years, 5 months

2
9
0 0

[Linux-stable-mirror] [PATCH v4.4] PM / OPP: Add missing of_node_put(np)

by Viresh Kumar

From: Tobias Jordan <Tobias.Jordan(a)elektrobit.com> commit 7978db344719dab1e56d05e6fc04aaaddcde0a5e upstream. The for_each_available_child_of_node() loop in _of_add_opp_table_v2() doesn't drop the reference to "np" on errors. Fix that. Fixes: 274659029c9d (PM / OPP: Add support to parse "operating-points-v2" bindings) Cc: 4.4 <stable(a)vger.kernel.org> # 4.4 Signed-off-by: Tobias Jordan <Tobias.Jordan(a)elektrobit.com> [ VK: Improved commit log. ] Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org> Reviewed-by: Stephen Boyd <sboyd(a)codeaurora.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> --- drivers/base/power/opp/core.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/base/power/opp/core.c b/drivers/base/power/opp/core.c index b8e76f75073b..0b4190a1efaa 100644 --- a/drivers/base/power/opp/core.c +++ b/drivers/base/power/opp/core.c @@ -1199,6 +1199,7 @@ static int _of_add_opp_table_v2(struct device *dev, struct device_node *opp_np) if (ret) { dev_err(dev, "%s: Failed to add OPP, %d\n", __func__, ret); ++ of_node_put(np); goto free_table; } } -- 2.15.0.194.g9af6a3dea062

7 years, 5 months

2
2
0 0

[Linux-stable-mirror] 4.9.62: intermittent flicker after upgrade from 4.9.61

by Rainer Fiebig

Hi! Hopefully the right addressee. Encountered two bad backports which cause screen-flicker. dmesg shows: ... [drm:ironlake_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun [drm:ironlake_irq_handler [i915]] *ERROR* PCH transcoder A FIFO underrun [drm:ironlake_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun [drm:ironlake_irq_handler [i915]] *ERROR* PCH transcoder B FIFO underrun ... CPU: Intel Core i3 (Clarkdale/Ironlake) The backports are: - diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index 49de476..277a802 100644 - diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h index a19ec06..3ce9ba3 100644 After reversing them the flicker is gone, no more messages in dmesg. All else OK so far. I have also reported this here: https://bugs.freedesktop.org/show_bug.cgi?id=103796 So long! Rainer Fiebig -- The truth always turns out to be simpler than you thought. Richard Feynman

7 years, 5 months

4
21
0 0

[Linux-stable-mirror] FAILED: patch "[PATCH] iwlwifi: fix PCI IDs and configuration mapping for 9000" failed to apply to 4.14-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.14-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From dbc89253a7e15f8f031fb1eeb956de91204655e3 Mon Sep 17 00:00:00 2001 From: Luca Coelho <luciano.coelho(a)intel.com> Date: Wed, 15 Nov 2017 18:28:04 +0200 Subject: [PATCH] iwlwifi: fix PCI IDs and configuration mapping for 9000 series A lot of PCI IDs were missing and there were some problems with the configuration and firmware selection for devices on the 9000 series. Fix the firmware selection by adding files for the B-steps; add configuration for some integrated devices; and add a bunch of PCI IDs (mostly for integrated devices) that were missing from the driver's list. Without this patch, a lot of devices will not be recognized or will try to load the wrong firmware file. Cc: stable(a)vger.kernel.org # 4.13 Signed-off-by: Luca Coelho <luciano.coelho(a)intel.com> diff --git a/drivers/net/wireless/intel/iwlwifi/cfg/9000.c b/drivers/net/wireless/intel/iwlwifi/cfg/9000.c index af7c4f36b66f..b6990400042f 100644 --- a/drivers/net/wireless/intel/iwlwifi/cfg/9000.c +++ b/drivers/net/wireless/intel/iwlwifi/cfg/9000.c @@ -72,12 +72,15 @@ #define IWL9000_SMEM_OFFSET 0x400000 #define IWL9000_SMEM_LEN 0x68000 -#define IWL9000_FW_PRE "iwlwifi-9000-pu-a0-jf-a0-" +#define IWL9000A_FW_PRE "iwlwifi-9000-pu-a0-jf-a0-" +#define IWL9000B_FW_PRE "iwlwifi-9000-pu-b0-jf-b0-" #define IWL9000RFB_FW_PRE "iwlwifi-9000-pu-a0-jf-b0-" #define IWL9260A_FW_PRE "iwlwifi-9260-th-a0-jf-a0-" #define IWL9260B_FW_PRE "iwlwifi-9260-th-b0-jf-b0-" -#define IWL9000_MODULE_FIRMWARE(api) \ - IWL9000_FW_PRE "-" __stringify(api) ".ucode" +#define IWL9000A_MODULE_FIRMWARE(api) \ + IWL9000A_FW_PRE __stringify(api) ".ucode" +#define IWL9000B_MODULE_FIRMWARE(api) \ + IWL9000B_FW_PRE __stringify(api) ".ucode" #define IWL9000RFB_MODULE_FIRMWARE(api) \ IWL9000RFB_FW_PRE "-" __stringify(api) ".ucode" #define IWL9260A_MODULE_FIRMWARE(api) \ @@ -194,7 +197,48 @@ const struct iwl_cfg iwl9460_2ac_cfg = { .nvm_ver = IWL9000_NVM_VERSION, .nvm_calib_ver = IWL9000_TX_POWER_VERSION, .max_ht_ampdu_exponent = IEEE80211_HT_MAX_AMPDU_64K, +}; + +const struct iwl_cfg iwl9460_2ac_cfg_soc = { + .name = "Intel(R) Dual Band Wireless AC 9460", + .fw_name_pre = IWL9000A_FW_PRE, + .fw_name_pre_b_or_c_step = IWL9000B_FW_PRE, + .fw_name_pre_rf_next_step = IWL9000RFB_FW_PRE, + IWL_DEVICE_9000, + .ht_params = &iwl9000_ht_params, + .nvm_ver = IWL9000_NVM_VERSION, + .nvm_calib_ver = IWL9000_TX_POWER_VERSION, + .max_ht_ampdu_exponent = IEEE80211_HT_MAX_AMPDU_64K, .integrated = true, + .soc_latency = 5000, +}; + +const struct iwl_cfg iwl9461_2ac_cfg_soc = { + .name = "Intel(R) Dual Band Wireless AC 9461", + .fw_name_pre = IWL9000A_FW_PRE, + .fw_name_pre_b_or_c_step = IWL9000B_FW_PRE, + .fw_name_pre_rf_next_step = IWL9000RFB_FW_PRE, + IWL_DEVICE_9000, + .ht_params = &iwl9000_ht_params, + .nvm_ver = IWL9000_NVM_VERSION, + .nvm_calib_ver = IWL9000_TX_POWER_VERSION, + .max_ht_ampdu_exponent = IEEE80211_HT_MAX_AMPDU_64K, + .integrated = true, + .soc_latency = 5000, +}; + +const struct iwl_cfg iwl9462_2ac_cfg_soc = { + .name = "Intel(R) Dual Band Wireless AC 9462", + .fw_name_pre = IWL9000A_FW_PRE, + .fw_name_pre_b_or_c_step = IWL9000B_FW_PRE, + .fw_name_pre_rf_next_step = IWL9000RFB_FW_PRE, + IWL_DEVICE_9000, + .ht_params = &iwl9000_ht_params, + .nvm_ver = IWL9000_NVM_VERSION, + .nvm_calib_ver = IWL9000_TX_POWER_VERSION, + .max_ht_ampdu_exponent = IEEE80211_HT_MAX_AMPDU_64K, + .integrated = true, + .soc_latency = 5000, }; const struct iwl_cfg iwl9560_2ac_cfg = { @@ -206,10 +250,23 @@ const struct iwl_cfg iwl9560_2ac_cfg = { .nvm_ver = IWL9000_NVM_VERSION, .nvm_calib_ver = IWL9000_TX_POWER_VERSION, .max_ht_ampdu_exponent = IEEE80211_HT_MAX_AMPDU_64K, - .integrated = true, }; -MODULE_FIRMWARE(IWL9000_MODULE_FIRMWARE(IWL9000_UCODE_API_MAX)); +const struct iwl_cfg iwl9560_2ac_cfg_soc = { + .name = "Intel(R) Dual Band Wireless AC 9560", + .fw_name_pre = IWL9000A_FW_PRE, + .fw_name_pre_b_or_c_step = IWL9000B_FW_PRE, + .fw_name_pre_rf_next_step = IWL9000RFB_FW_PRE, + IWL_DEVICE_9000, + .ht_params = &iwl9000_ht_params, + .nvm_ver = IWL9000_NVM_VERSION, + .nvm_calib_ver = IWL9000_TX_POWER_VERSION, + .max_ht_ampdu_exponent = IEEE80211_HT_MAX_AMPDU_64K, + .integrated = true, + .soc_latency = 5000, +}; +MODULE_FIRMWARE(IWL9000A_MODULE_FIRMWARE(IWL9000_UCODE_API_MAX)); +MODULE_FIRMWARE(IWL9000B_MODULE_FIRMWARE(IWL9000_UCODE_API_MAX)); MODULE_FIRMWARE(IWL9000RFB_MODULE_FIRMWARE(IWL9000_UCODE_API_MAX)); MODULE_FIRMWARE(IWL9260A_MODULE_FIRMWARE(IWL9000_UCODE_API_MAX)); MODULE_FIRMWARE(IWL9260B_MODULE_FIRMWARE(IWL9000_UCODE_API_MAX)); diff --git a/drivers/net/wireless/intel/iwlwifi/iwl-config.h b/drivers/net/wireless/intel/iwlwifi/iwl-config.h index d1263a554420..e21e46cf6f9a 100644 --- a/drivers/net/wireless/intel/iwlwifi/iwl-config.h +++ b/drivers/net/wireless/intel/iwlwifi/iwl-config.h @@ -366,6 +366,7 @@ struct iwl_cfg { u32 dccm2_len; u32 smem_offset; u32 smem_len; + u32 soc_latency; u16 nvm_ver; u16 nvm_calib_ver; u16 rx_with_siso_diversity:1, @@ -472,6 +473,10 @@ extern const struct iwl_cfg iwl9260_2ac_cfg; extern const struct iwl_cfg iwl9270_2ac_cfg; extern const struct iwl_cfg iwl9460_2ac_cfg; extern const struct iwl_cfg iwl9560_2ac_cfg; +extern const struct iwl_cfg iwl9460_2ac_cfg_soc; +extern const struct iwl_cfg iwl9461_2ac_cfg_soc; +extern const struct iwl_cfg iwl9462_2ac_cfg_soc; +extern const struct iwl_cfg iwl9560_2ac_cfg_soc; extern const struct iwl_cfg iwla000_2ac_cfg_hr; extern const struct iwl_cfg iwla000_2ac_cfg_hr_cdb; extern const struct iwl_cfg iwla000_2ac_cfg_jf; diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/drv.c b/drivers/net/wireless/intel/iwlwifi/pcie/drv.c index 4a21c12276d7..f21fe59faccf 100644 --- a/drivers/net/wireless/intel/iwlwifi/pcie/drv.c +++ b/drivers/net/wireless/intel/iwlwifi/pcie/drv.c @@ -535,47 +535,121 @@ static const struct pci_device_id iwl_hw_card_ids[] = { {IWL_PCI_DEVICE(0x2526, 0x0238, iwl9560_2ac_cfg)}, {IWL_PCI_DEVICE(0x2526, 0x023C, iwl9560_2ac_cfg)}, {IWL_PCI_DEVICE(0x2526, 0x0260, iwl9460_2ac_cfg)}, + {IWL_PCI_DEVICE(0x2526, 0x0264, iwl9461_2ac_cfg_soc)}, {IWL_PCI_DEVICE(0x2526, 0x02A0, iwl9460_2ac_cfg)}, {IWL_PCI_DEVICE(0x2526, 0x02A4, iwl9460_2ac_cfg)}, + {IWL_PCI_DEVICE(0x2526, 0x1010, iwl9260_2ac_cfg)}, {IWL_PCI_DEVICE(0x2526, 0x1030, iwl9560_2ac_cfg)}, + {IWL_PCI_DEVICE(0x2526, 0x1210, iwl9260_2ac_cfg)}, {IWL_PCI_DEVICE(0x2526, 0x1410, iwl9270_2ac_cfg)}, - {IWL_PCI_DEVICE(0x2526, 0x1420, iwl9460_2ac_cfg)}, + {IWL_PCI_DEVICE(0x2526, 0x1420, iwl9460_2ac_cfg_soc)}, {IWL_PCI_DEVICE(0x2526, 0x1610, iwl9270_2ac_cfg)}, {IWL_PCI_DEVICE(0x2526, 0x4010, iwl9260_2ac_cfg)}, {IWL_PCI_DEVICE(0x2526, 0x4030, iwl9560_2ac_cfg)}, {IWL_PCI_DEVICE(0x2526, 0x40A4, iwl9460_2ac_cfg)}, {IWL_PCI_DEVICE(0x2526, 0xA014, iwl9260_2ac_cfg)}, + {IWL_PCI_DEVICE(0x2526, 0x42A4, iwl9462_2ac_cfg_soc)}, {IWL_PCI_DEVICE(0x271B, 0x0010, iwl9160_2ac_cfg)}, {IWL_PCI_DEVICE(0x271B, 0x0014, iwl9160_2ac_cfg)}, {IWL_PCI_DEVICE(0x271B, 0x0210, iwl9160_2ac_cfg)}, - {IWL_PCI_DEVICE(0x30DC, 0x0060, iwl9460_2ac_cfg)}, - {IWL_PCI_DEVICE(0x31DC, 0x0030, iwl9560_2ac_cfg)}, - {IWL_PCI_DEVICE(0x31DC, 0x0034, iwl9560_2ac_cfg)}, - {IWL_PCI_DEVICE(0x31DC, 0x0038, iwl9560_2ac_cfg)}, - {IWL_PCI_DEVICE(0x31DC, 0x003C, iwl9560_2ac_cfg)}, - {IWL_PCI_DEVICE(0x31DC, 0x0060, iwl9460_2ac_cfg)}, - {IWL_PCI_DEVICE(0x9DF0, 0x0000, iwl9460_2ac_cfg)}, - {IWL_PCI_DEVICE(0x9DF0, 0x0010, iwl9460_2ac_cfg)}, - {IWL_PCI_DEVICE(0x9DF0, 0x0030, iwl9560_2ac_cfg)}, - {IWL_PCI_DEVICE(0x9DF0, 0x0034, iwl9560_2ac_cfg)}, - {IWL_PCI_DEVICE(0x9DF0, 0x0038, iwl9560_2ac_cfg)}, - {IWL_PCI_DEVICE(0x9DF0, 0x003C, iwl9560_2ac_cfg)}, - {IWL_PCI_DEVICE(0x9DF0, 0x0060, iwl9460_2ac_cfg)}, - {IWL_PCI_DEVICE(0x9DF0, 0x0210, iwl9460_2ac_cfg)}, - {IWL_PCI_DEVICE(0x9DF0, 0x0310, iwl9460_2ac_cfg)}, - {IWL_PCI_DEVICE(0x9DF0, 0x0410, iwl9460_2ac_cfg)}, - {IWL_PCI_DEVICE(0x9DF0, 0x0510, iwl9460_2ac_cfg)}, - {IWL_PCI_DEVICE(0x9DF0, 0x0610, iwl9460_2ac_cfg)}, - {IWL_PCI_DEVICE(0x9DF0, 0x0710, iwl9460_2ac_cfg)}, - {IWL_PCI_DEVICE(0x9DF0, 0x0A10, iwl9460_2ac_cfg)}, - {IWL_PCI_DEVICE(0x9DF0, 0x2010, iwl9460_2ac_cfg)}, - {IWL_PCI_DEVICE(0x9DF0, 0x2A10, iwl9460_2ac_cfg)}, - {IWL_PCI_DEVICE(0xA370, 0x0030, iwl9560_2ac_cfg)}, - {IWL_PCI_DEVICE(0xA370, 0x0034, iwl9560_2ac_cfg)}, - {IWL_PCI_DEVICE(0xA370, 0x0038, iwl9560_2ac_cfg)}, - {IWL_PCI_DEVICE(0xA370, 0x003C, iwl9560_2ac_cfg)}, - {IWL_PCI_DEVICE(0xA370, 0x0060, iwl9460_2ac_cfg)}, - {IWL_PCI_DEVICE(0xA370, 0x1030, iwl9560_2ac_cfg)}, + {IWL_PCI_DEVICE(0x271B, 0x0214, iwl9260_2ac_cfg)}, + {IWL_PCI_DEVICE(0x2720, 0x0034, iwl9560_2ac_cfg)}, + {IWL_PCI_DEVICE(0x2720, 0x0038, iwl9560_2ac_cfg)}, + {IWL_PCI_DEVICE(0x2720, 0x003C, iwl9560_2ac_cfg)}, + {IWL_PCI_DEVICE(0x2720, 0x0060, iwl9461_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x2720, 0x0064, iwl9461_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x2720, 0x00A0, iwl9462_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x2720, 0x00A4, iwl9462_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x2720, 0x0230, iwl9560_2ac_cfg)}, + {IWL_PCI_DEVICE(0x2720, 0x0234, iwl9560_2ac_cfg)}, + {IWL_PCI_DEVICE(0x2720, 0x0238, iwl9560_2ac_cfg)}, + {IWL_PCI_DEVICE(0x2720, 0x023C, iwl9560_2ac_cfg)}, + {IWL_PCI_DEVICE(0x2720, 0x0260, iwl9461_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x2720, 0x0264, iwl9461_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x2720, 0x02A0, iwl9462_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x2720, 0x02A4, iwl9462_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x2720, 0x4030, iwl9560_2ac_cfg)}, + {IWL_PCI_DEVICE(0x2720, 0x40A4, iwl9462_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x30DC, 0x0060, iwl9460_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x30DC, 0x0064, iwl9461_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x30DC, 0x00A0, iwl9462_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x30DC, 0x00A4, iwl9462_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x30DC, 0x0260, iwl9461_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x30DC, 0x0264, iwl9461_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x30DC, 0x02A0, iwl9462_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x30DC, 0x02A4, iwl9462_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x31DC, 0x0030, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x31DC, 0x0034, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x31DC, 0x0038, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x31DC, 0x003C, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x31DC, 0x0060, iwl9460_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x31DC, 0x0064, iwl9461_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x31DC, 0x00A0, iwl9462_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x31DC, 0x00A4, iwl9462_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x31DC, 0x0230, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x31DC, 0x0234, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x31DC, 0x0238, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x31DC, 0x023C, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x31DC, 0x0260, iwl9461_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x31DC, 0x0264, iwl9461_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x31DC, 0x02A0, iwl9462_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x31DC, 0x02A4, iwl9462_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x31DC, 0x4030, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x31DC, 0x4034, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x31DC, 0x40A4, iwl9462_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x34F0, 0x0030, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x34F0, 0x0034, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x34F0, 0x02A4, iwl9462_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x9DF0, 0x0000, iwl9460_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x9DF0, 0x0010, iwl9460_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x9DF0, 0x0030, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x9DF0, 0x0034, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x9DF0, 0x0038, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x9DF0, 0x003C, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x9DF0, 0x0060, iwl9460_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x9DF0, 0x0064, iwl9461_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x9DF0, 0x00A0, iwl9462_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x9DF0, 0x00A4, iwl9462_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x9DF0, 0x0210, iwl9460_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x9DF0, 0x0230, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x9DF0, 0x0234, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x9DF0, 0x0238, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x9DF0, 0x023C, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x9DF0, 0x0260, iwl9461_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x9DF0, 0x0264, iwl9461_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x9DF0, 0x02A0, iwl9462_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x9DF0, 0x02A4, iwl9462_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x9DF0, 0x0310, iwl9460_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x9DF0, 0x0410, iwl9460_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x9DF0, 0x0510, iwl9460_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x9DF0, 0x0610, iwl9460_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x9DF0, 0x0710, iwl9460_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x9DF0, 0x0A10, iwl9460_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x9DF0, 0x2010, iwl9460_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x9DF0, 0x2A10, iwl9460_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x9DF0, 0x4030, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x9DF0, 0x4034, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x9DF0, 0x40A4, iwl9462_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0xA370, 0x0030, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0xA370, 0x0034, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0xA370, 0x0038, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0xA370, 0x003C, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0xA370, 0x0060, iwl9460_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0xA370, 0x0064, iwl9461_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0xA370, 0x00A0, iwl9462_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0xA370, 0x00A4, iwl9462_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0xA370, 0x0230, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0xA370, 0x0234, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0xA370, 0x0238, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0xA370, 0x023C, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0xA370, 0x0260, iwl9461_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0xA370, 0x0264, iwl9461_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0xA370, 0x02A0, iwl9462_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0xA370, 0x02A4, iwl9462_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0xA370, 0x1030, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0xA370, 0x4030, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0xA370, 0x4034, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0xA370, 0x40A4, iwl9462_2ac_cfg_soc)}, /* a000 Series */ {IWL_PCI_DEVICE(0x2720, 0x0A10, iwla000_2ac_cfg_hr_cdb)},

7 years, 5 months

5
6
0 0

[Linux-stable-mirror] Patch "iwlwifi: pcie: sort IDs for the 9000 series for easier comparisons" 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 iwlwifi: pcie: sort IDs for the 9000 series for easier comparisons 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: iwlwifi-pcie-sort-ids-for-the-9000-series-for-easier-comparisons.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 1105a337375258515ed09b92a83fd7bfd6775958 Mon Sep 17 00:00:00 2001 From: Luca Coelho <luciano.coelho(a)intel.com> Date: Thu, 12 Oct 2017 11:20:50 +0300 Subject: iwlwifi: pcie: sort IDs for the 9000 series for easier comparisons From: Luca Coelho <luciano.coelho(a)intel.com> commit 1105a337375258515ed09b92a83fd7bfd6775958 upstream. It's hard to find values that are missing in the list, so sorting the values and comparing them makes it much easier. To simplify this task, sort the devices in the list. Signed-off-by: Luca Coelho <luciano.coelho(a)intel.com> Cc: Thomas Backlund <tmb(a)mageia.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/wireless/intel/iwlwifi/pcie/drv.c | 84 +++++++++++++------------- 1 file changed, 42 insertions(+), 42 deletions(-) --- a/drivers/net/wireless/intel/iwlwifi/pcie/drv.c +++ b/drivers/net/wireless/intel/iwlwifi/pcie/drv.c @@ -510,65 +510,65 @@ static const struct pci_device_id iwl_hw {IWL_PCI_DEVICE(0x24FD, 0x0012, iwl8275_2ac_cfg)}, /* 9000 Series */ - {IWL_PCI_DEVICE(0x271B, 0x0010, iwl9160_2ac_cfg)}, - {IWL_PCI_DEVICE(0x271B, 0x0014, iwl9160_2ac_cfg)}, - {IWL_PCI_DEVICE(0x271B, 0x0210, iwl9160_2ac_cfg)}, {IWL_PCI_DEVICE(0x2526, 0x0000, iwl9260_2ac_cfg)}, {IWL_PCI_DEVICE(0x2526, 0x0010, iwl9260_2ac_cfg)}, {IWL_PCI_DEVICE(0x2526, 0x0014, iwl9260_2ac_cfg)}, - {IWL_PCI_DEVICE(0x2526, 0xA014, iwl9260_2ac_cfg)}, - {IWL_PCI_DEVICE(0x2526, 0x4010, iwl9260_2ac_cfg)}, + {IWL_PCI_DEVICE(0x2526, 0x0030, iwl9560_2ac_cfg)}, + {IWL_PCI_DEVICE(0x2526, 0x0034, iwl9560_2ac_cfg)}, + {IWL_PCI_DEVICE(0x2526, 0x0038, iwl9560_2ac_cfg)}, + {IWL_PCI_DEVICE(0x2526, 0x003C, iwl9560_2ac_cfg)}, + {IWL_PCI_DEVICE(0x2526, 0x0060, iwl9460_2ac_cfg)}, + {IWL_PCI_DEVICE(0x2526, 0x0064, iwl9460_2ac_cfg)}, + {IWL_PCI_DEVICE(0x2526, 0x00A0, iwl9460_2ac_cfg)}, + {IWL_PCI_DEVICE(0x2526, 0x00A4, iwl9460_2ac_cfg)}, {IWL_PCI_DEVICE(0x2526, 0x0210, iwl9260_2ac_cfg)}, {IWL_PCI_DEVICE(0x2526, 0x0214, iwl9260_2ac_cfg)}, + {IWL_PCI_DEVICE(0x2526, 0x0230, iwl9560_2ac_cfg)}, + {IWL_PCI_DEVICE(0x2526, 0x0234, iwl9560_2ac_cfg)}, + {IWL_PCI_DEVICE(0x2526, 0x0238, iwl9560_2ac_cfg)}, + {IWL_PCI_DEVICE(0x2526, 0x023C, iwl9560_2ac_cfg)}, + {IWL_PCI_DEVICE(0x2526, 0x0260, iwl9460_2ac_cfg)}, + {IWL_PCI_DEVICE(0x2526, 0x02A0, iwl9460_2ac_cfg)}, + {IWL_PCI_DEVICE(0x2526, 0x02A4, iwl9460_2ac_cfg)}, + {IWL_PCI_DEVICE(0x2526, 0x1030, iwl9560_2ac_cfg)}, {IWL_PCI_DEVICE(0x2526, 0x1410, iwl9270_2ac_cfg)}, + {IWL_PCI_DEVICE(0x2526, 0x1420, iwl9460_2ac_cfg)}, {IWL_PCI_DEVICE(0x2526, 0x1610, iwl9270_2ac_cfg)}, - {IWL_PCI_DEVICE(0x9DF0, 0x0A10, iwl9460_2ac_cfg)}, + {IWL_PCI_DEVICE(0x2526, 0x4010, iwl9260_2ac_cfg)}, + {IWL_PCI_DEVICE(0x2526, 0x4030, iwl9560_2ac_cfg)}, + {IWL_PCI_DEVICE(0x2526, 0x40A4, iwl9460_2ac_cfg)}, + {IWL_PCI_DEVICE(0x2526, 0xA014, iwl9260_2ac_cfg)}, + {IWL_PCI_DEVICE(0x271B, 0x0010, iwl9160_2ac_cfg)}, + {IWL_PCI_DEVICE(0x271B, 0x0014, iwl9160_2ac_cfg)}, + {IWL_PCI_DEVICE(0x271B, 0x0210, iwl9160_2ac_cfg)}, + {IWL_PCI_DEVICE(0x30DC, 0x0060, iwl9460_2ac_cfg)}, + {IWL_PCI_DEVICE(0x31DC, 0x0030, iwl9560_2ac_cfg)}, + {IWL_PCI_DEVICE(0x31DC, 0x0034, iwl9560_2ac_cfg)}, + {IWL_PCI_DEVICE(0x31DC, 0x0038, iwl9560_2ac_cfg)}, + {IWL_PCI_DEVICE(0x31DC, 0x003C, iwl9560_2ac_cfg)}, + {IWL_PCI_DEVICE(0x31DC, 0x0060, iwl9460_2ac_cfg)}, + {IWL_PCI_DEVICE(0x9DF0, 0x0000, iwl9460_2ac_cfg)}, {IWL_PCI_DEVICE(0x9DF0, 0x0010, iwl9460_2ac_cfg)}, + {IWL_PCI_DEVICE(0x9DF0, 0x0030, iwl9560_2ac_cfg)}, + {IWL_PCI_DEVICE(0x9DF0, 0x0034, iwl9560_2ac_cfg)}, + {IWL_PCI_DEVICE(0x9DF0, 0x0038, iwl9560_2ac_cfg)}, + {IWL_PCI_DEVICE(0x9DF0, 0x003C, iwl9560_2ac_cfg)}, + {IWL_PCI_DEVICE(0x9DF0, 0x0060, iwl9460_2ac_cfg)}, {IWL_PCI_DEVICE(0x9DF0, 0x0210, iwl9460_2ac_cfg)}, - {IWL_PCI_DEVICE(0x9DF0, 0x0410, iwl9460_2ac_cfg)}, - {IWL_PCI_DEVICE(0x9DF0, 0x0610, iwl9460_2ac_cfg)}, {IWL_PCI_DEVICE(0x9DF0, 0x0310, iwl9460_2ac_cfg)}, - {IWL_PCI_DEVICE(0x9DF0, 0x0000, iwl9460_2ac_cfg)}, + {IWL_PCI_DEVICE(0x9DF0, 0x0410, iwl9460_2ac_cfg)}, {IWL_PCI_DEVICE(0x9DF0, 0x0510, iwl9460_2ac_cfg)}, - {IWL_PCI_DEVICE(0x9DF0, 0x2010, iwl9460_2ac_cfg)}, - {IWL_PCI_DEVICE(0x2526, 0x1420, iwl9460_2ac_cfg)}, + {IWL_PCI_DEVICE(0x9DF0, 0x0610, iwl9460_2ac_cfg)}, {IWL_PCI_DEVICE(0x9DF0, 0x0710, iwl9460_2ac_cfg)}, + {IWL_PCI_DEVICE(0x9DF0, 0x0A10, iwl9460_2ac_cfg)}, + {IWL_PCI_DEVICE(0x9DF0, 0x2010, iwl9460_2ac_cfg)}, {IWL_PCI_DEVICE(0x9DF0, 0x2A10, iwl9460_2ac_cfg)}, - {IWL_PCI_DEVICE(0x30DC, 0x0060, iwl9460_2ac_cfg)}, - {IWL_PCI_DEVICE(0x2526, 0x0060, iwl9460_2ac_cfg)}, - {IWL_PCI_DEVICE(0x2526, 0x0260, iwl9460_2ac_cfg)}, - {IWL_PCI_DEVICE(0x2526, 0x0064, iwl9460_2ac_cfg)}, - {IWL_PCI_DEVICE(0x2526, 0x00A4, iwl9460_2ac_cfg)}, - {IWL_PCI_DEVICE(0x2526, 0x40A4, iwl9460_2ac_cfg)}, - {IWL_PCI_DEVICE(0x2526, 0x02A4, iwl9460_2ac_cfg)}, - {IWL_PCI_DEVICE(0x2526, 0x00A0, iwl9460_2ac_cfg)}, - {IWL_PCI_DEVICE(0x2526, 0x02A0, iwl9460_2ac_cfg)}, - {IWL_PCI_DEVICE(0x9DF0, 0x0060, iwl9460_2ac_cfg)}, - {IWL_PCI_DEVICE(0xA370, 0x0060, iwl9460_2ac_cfg)}, - {IWL_PCI_DEVICE(0x31DC, 0x0060, iwl9460_2ac_cfg)}, - {IWL_PCI_DEVICE(0x2526, 0x0030, iwl9560_2ac_cfg)}, - {IWL_PCI_DEVICE(0x2526, 0x4030, iwl9560_2ac_cfg)}, - {IWL_PCI_DEVICE(0x2526, 0x0230, iwl9560_2ac_cfg)}, - {IWL_PCI_DEVICE(0x2526, 0x0234, iwl9560_2ac_cfg)}, - {IWL_PCI_DEVICE(0x2526, 0x0238, iwl9560_2ac_cfg)}, - {IWL_PCI_DEVICE(0x2526, 0x023C, iwl9560_2ac_cfg)}, - {IWL_PCI_DEVICE(0x9DF0, 0x0030, iwl9560_2ac_cfg)}, {IWL_PCI_DEVICE(0xA370, 0x0030, iwl9560_2ac_cfg)}, - {IWL_PCI_DEVICE(0x31DC, 0x0030, iwl9560_2ac_cfg)}, - {IWL_PCI_DEVICE(0x2526, 0x1030, iwl9560_2ac_cfg)}, - {IWL_PCI_DEVICE(0xA370, 0x1030, iwl9560_2ac_cfg)}, - {IWL_PCI_DEVICE(0x9DF0, 0x0034, iwl9560_2ac_cfg)}, {IWL_PCI_DEVICE(0xA370, 0x0034, iwl9560_2ac_cfg)}, - {IWL_PCI_DEVICE(0x31DC, 0x0034, iwl9560_2ac_cfg)}, - {IWL_PCI_DEVICE(0x2526, 0x0038, iwl9560_2ac_cfg)}, - {IWL_PCI_DEVICE(0x2526, 0x003C, iwl9560_2ac_cfg)}, - {IWL_PCI_DEVICE(0x9DF0, 0x0038, iwl9560_2ac_cfg)}, {IWL_PCI_DEVICE(0xA370, 0x0038, iwl9560_2ac_cfg)}, - {IWL_PCI_DEVICE(0x31DC, 0x0038, iwl9560_2ac_cfg)}, - {IWL_PCI_DEVICE(0x9DF0, 0x003C, iwl9560_2ac_cfg)}, {IWL_PCI_DEVICE(0xA370, 0x003C, iwl9560_2ac_cfg)}, - {IWL_PCI_DEVICE(0x31DC, 0x003C, iwl9560_2ac_cfg)}, - {IWL_PCI_DEVICE(0x2526, 0x0034, iwl9560_2ac_cfg)}, + {IWL_PCI_DEVICE(0xA370, 0x0060, iwl9460_2ac_cfg)}, + {IWL_PCI_DEVICE(0xA370, 0x1030, iwl9560_2ac_cfg)}, /* a000 Series */ {IWL_PCI_DEVICE(0x2720, 0x0A10, iwla000_2ac_cfg_hr_cdb)}, Patches currently in stable-queue which might be from luciano.coelho(a)intel.com are queue-4.14/iwlwifi-fix-firmware-names-for-9000-and-a000-series-hw.patch queue-4.14/iwlwifi-fix-wrong-struct-for-a000-device.patch queue-4.14/iwlwifi-add-new-cards-for-8265-series.patch queue-4.14/iwlwifi-pcie-sort-ids-for-the-9000-series-for-easier-comparisons.patch queue-4.14/iwlwifi-fix-pci-ids-and-configuration-mapping-for-9000-series.patch queue-4.14/iwlwifi-add-new-cards-for-a000-series.patch queue-4.14/iwlwifi-mvm-support-version-7-of-the-scan_req_umac-fw-command.patch queue-4.14/iwlwifi-add-a-new-a000-device.patch queue-4.14/iwlwifi-add-new-cards-for-8260-series.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "iwlwifi: mvm: support version 7 of the SCAN_REQ_UMAC FW command" 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 iwlwifi: mvm: support version 7 of the SCAN_REQ_UMAC FW command 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: iwlwifi-mvm-support-version-7-of-the-scan_req_umac-fw-command.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 dac4df1c5f2c34903f61b1bc4fc722e31b4199e7 Mon Sep 17 00:00:00 2001 From: Luca Coelho <luciano.coelho(a)intel.com> Date: Fri, 10 Nov 2017 14:03:36 +0200 Subject: iwlwifi: mvm: support version 7 of the SCAN_REQ_UMAC FW command From: Luca Coelho <luciano.coelho(a)intel.com> commit dac4df1c5f2c34903f61b1bc4fc722e31b4199e7 upstream. Newer firmware versions (such as iwlwifi-8000C-34.ucode) have introduced an API change in the SCAN_REQ_UMAC command that is not backwards compatible. The driver needs to detect and use the new API format when the firmware reports it, otherwise the scan command will not work properly, causing a command timeout. Fix this by adding a TLV that tells the driver that the new API is in use and use the correct structures for it. This fixes https://bugzilla.kernel.org/show_bug.cgi?id=197591 Fixes: d7a5b3e9e42e ("iwlwifi: mvm: bump API to 34 for 8000 and up") Signed-off-by: Luca Coelho <luciano.coelho(a)intel.com> Cc: Thomas Backlund <tmb(a)mageia.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/wireless/intel/iwlwifi/fw/api/scan.h | 59 ++++++++++++--- drivers/net/wireless/intel/iwlwifi/fw/file.h | 1 drivers/net/wireless/intel/iwlwifi/mvm/mvm.h | 6 + drivers/net/wireless/intel/iwlwifi/mvm/scan.c | 86 +++++++++++++++++------ 4 files changed, 118 insertions(+), 34 deletions(-) --- a/drivers/net/wireless/intel/iwlwifi/fw/api/scan.h +++ b/drivers/net/wireless/intel/iwlwifi/fw/api/scan.h @@ -531,6 +531,8 @@ struct iwl_scan_config_v1 { } __packed; /* SCAN_CONFIG_DB_CMD_API_S */ #define SCAN_TWO_LMACS 2 +#define SCAN_LB_LMAC_IDX 0 +#define SCAN_HB_LMAC_IDX 1 struct iwl_scan_config { __le32 flags; @@ -578,6 +580,7 @@ enum iwl_umac_scan_general_flags { IWL_UMAC_SCAN_GEN_FLAGS_MATCH = BIT(9), IWL_UMAC_SCAN_GEN_FLAGS_EXTENDED_DWELL = BIT(10), IWL_UMAC_SCAN_GEN_FLAGS_LMAC2_FRAGMENTED = BIT(11), + IWL_UMAC_SCAN_GEN_FLAGS_ADAPTIVE_DWELL = BIT(13), }; /** @@ -631,12 +634,17 @@ struct iwl_scan_req_umac_tail { * @uid: scan id, &enum iwl_umac_scan_uid_offsets * @ooc_priority: out of channel priority - &enum iwl_scan_priority * @general_flags: &enum iwl_umac_scan_general_flags - * @reserved2: for future use and alignment * @scan_start_mac_id: report the scan start TSF time according to this mac TSF * @extended_dwell: dwell time for channels 1, 6 and 11 * @active_dwell: dwell time for active scan * @passive_dwell: dwell time for passive scan * @fragmented_dwell: dwell time for fragmented passive scan + * @adwell_default_n_aps: for adaptive dwell the default number of APs + * per channel + * @adwell_default_n_aps_social: for adaptive dwell the default + * number of APs per social (1,6,11) channel + * @adwell_max_budget: for adaptive dwell the maximal budget of TU to be added + * to total scan time * @max_out_time: max out of serving channel time, per LMAC - for CDB there * are 2 LMACs * @suspend_time: max suspend time, per LMAC - for CDB there are 2 LMACs @@ -644,6 +652,8 @@ struct iwl_scan_req_umac_tail { * @channel_flags: &enum iwl_scan_channel_flags * @n_channels: num of channels in scan request * @reserved: for future use and alignment + * @reserved2: for future use and alignment + * @reserved3: for future use and alignment * @data: &struct iwl_scan_channel_cfg_umac and * &struct iwl_scan_req_umac_tail */ @@ -651,41 +661,64 @@ struct iwl_scan_req_umac { __le32 flags; __le32 uid; __le32 ooc_priority; - /* SCAN_GENERAL_PARAMS_API_S_VER_4 */ __le16 general_flags; - u8 reserved2; + u8 reserved; u8 scan_start_mac_id; - u8 extended_dwell; - u8 active_dwell; - u8 passive_dwell; - u8 fragmented_dwell; union { struct { + u8 extended_dwell; + u8 active_dwell; + u8 passive_dwell; + u8 fragmented_dwell; __le32 max_out_time; __le32 suspend_time; __le32 scan_priority; - /* SCAN_CHANNEL_PARAMS_API_S_VER_4 */ + /* SCAN_CHANNEL_PARAMS_API_S_VER_1 */ u8 channel_flags; u8 n_channels; - __le16 reserved; + __le16 reserved2; u8 data[]; } v1; /* SCAN_REQUEST_CMD_UMAC_API_S_VER_1 */ struct { + u8 extended_dwell; + u8 active_dwell; + u8 passive_dwell; + u8 fragmented_dwell; __le32 max_out_time[SCAN_TWO_LMACS]; __le32 suspend_time[SCAN_TWO_LMACS]; __le32 scan_priority; - /* SCAN_CHANNEL_PARAMS_API_S_VER_4 */ + /* SCAN_CHANNEL_PARAMS_API_S_VER_1 */ u8 channel_flags; u8 n_channels; - __le16 reserved; + __le16 reserved2; u8 data[]; } v6; /* SCAN_REQUEST_CMD_UMAC_API_S_VER_6 */ + struct { + u8 active_dwell; + u8 passive_dwell; + u8 fragmented_dwell; + u8 adwell_default_n_aps; + u8 adwell_default_n_aps_social; + u8 reserved3; + __le16 adwell_max_budget; + __le32 max_out_time[SCAN_TWO_LMACS]; + __le32 suspend_time[SCAN_TWO_LMACS]; + __le32 scan_priority; + /* SCAN_CHANNEL_PARAMS_API_S_VER_1 */ + u8 channel_flags; + u8 n_channels; + __le16 reserved2; + u8 data[]; + } v7; /* SCAN_REQUEST_CMD_UMAC_API_S_VER_7 */ }; } __packed; -#define IWL_SCAN_REQ_UMAC_SIZE sizeof(struct iwl_scan_req_umac) +#define IWL_SCAN_REQ_UMAC_SIZE_V7 sizeof(struct iwl_scan_req_umac) +#define IWL_SCAN_REQ_UMAC_SIZE_V6 (sizeof(struct iwl_scan_req_umac) - \ + 2 * sizeof(u8) - sizeof(__le16)) #define IWL_SCAN_REQ_UMAC_SIZE_V1 (sizeof(struct iwl_scan_req_umac) - \ - 2 * sizeof(__le32)) + 2 * sizeof(__le32) - 2 * sizeof(u8) - \ + sizeof(__le16)) /** * struct iwl_umac_scan_abort --- a/drivers/net/wireless/intel/iwlwifi/fw/file.h +++ b/drivers/net/wireless/intel/iwlwifi/fw/file.h @@ -262,6 +262,7 @@ enum iwl_ucode_tlv_api { IWL_UCODE_TLV_API_STA_TYPE = (__force iwl_ucode_tlv_api_t)30, IWL_UCODE_TLV_API_NAN2_VER2 = (__force iwl_ucode_tlv_api_t)31, /* API Set 1 */ + IWL_UCODE_TLV_API_ADAPTIVE_DWELL = (__force iwl_ucode_tlv_api_t)32, IWL_UCODE_TLV_API_NEW_BEACON_TEMPLATE = (__force iwl_ucode_tlv_api_t)34, IWL_UCODE_TLV_API_NEW_RX_STATS = (__force iwl_ucode_tlv_api_t)35, IWL_UCODE_TLV_API_COEX_ATS_EXTERNAL = (__force iwl_ucode_tlv_api_t)37, --- a/drivers/net/wireless/intel/iwlwifi/mvm/mvm.h +++ b/drivers/net/wireless/intel/iwlwifi/mvm/mvm.h @@ -1124,6 +1124,12 @@ static inline bool iwl_mvm_is_d0i3_suppo IWL_UCODE_TLV_CAPA_D0I3_SUPPORT); } +static inline bool iwl_mvm_is_adaptive_dwell_supported(struct iwl_mvm *mvm) +{ + return fw_has_api(&mvm->fw->ucode_capa, + IWL_UCODE_TLV_API_ADAPTIVE_DWELL); +} + static inline bool iwl_mvm_enter_d0i3_on_suspend(struct iwl_mvm *mvm) { /* For now we only use this mode to differentiate between --- a/drivers/net/wireless/intel/iwlwifi/mvm/scan.c +++ b/drivers/net/wireless/intel/iwlwifi/mvm/scan.c @@ -130,6 +130,19 @@ struct iwl_mvm_scan_params { u32 measurement_dwell; }; +static inline void *iwl_mvm_get_scan_req_umac_data(struct iwl_mvm *mvm) +{ + struct iwl_scan_req_umac *cmd = mvm->scan_cmd; + + if (iwl_mvm_is_adaptive_dwell_supported(mvm)) + return (void *)&cmd->v7.data; + + if (iwl_mvm_has_new_tx_api(mvm)) + return (void *)&cmd->v6.data; + + return (void *)&cmd->v1.data; +} + static u8 iwl_mvm_scan_rx_ant(struct iwl_mvm *mvm) { if (mvm->scan_rx_ant != ANT_NONE) @@ -1075,25 +1088,57 @@ static void iwl_mvm_scan_umac_dwell(stru { struct iwl_mvm_scan_timing_params *timing = &scan_timing[params->type]; + if (iwl_mvm_is_regular_scan(params)) + cmd->ooc_priority = cpu_to_le32(IWL_SCAN_PRIORITY_EXT_6); + else + cmd->ooc_priority = cpu_to_le32(IWL_SCAN_PRIORITY_EXT_2); + + if (iwl_mvm_is_adaptive_dwell_supported(mvm)) { + if (params->measurement_dwell) { + cmd->v7.active_dwell = params->measurement_dwell; + cmd->v7.passive_dwell = params->measurement_dwell; + } else { + cmd->v7.active_dwell = IWL_SCAN_DWELL_ACTIVE; + cmd->v7.passive_dwell = IWL_SCAN_DWELL_PASSIVE; + } + cmd->v7.fragmented_dwell = IWL_SCAN_DWELL_FRAGMENTED; + + cmd->v7.scan_priority = cpu_to_le32(IWL_SCAN_PRIORITY_EXT_6); + cmd->v7.max_out_time[SCAN_LB_LMAC_IDX] = + cpu_to_le32(timing->max_out_time); + cmd->v7.suspend_time[SCAN_LB_LMAC_IDX] = + cpu_to_le32(timing->suspend_time); + if (iwl_mvm_is_cdb_supported(mvm)) { + cmd->v7.max_out_time[SCAN_HB_LMAC_IDX] = + cpu_to_le32(timing->max_out_time); + cmd->v7.suspend_time[SCAN_HB_LMAC_IDX] = + cpu_to_le32(timing->suspend_time); + } + + return; + } + if (params->measurement_dwell) { - cmd->active_dwell = params->measurement_dwell; - cmd->passive_dwell = params->measurement_dwell; - cmd->extended_dwell = params->measurement_dwell; + cmd->v1.active_dwell = params->measurement_dwell; + cmd->v1.passive_dwell = params->measurement_dwell; + cmd->v1.extended_dwell = params->measurement_dwell; } else { - cmd->active_dwell = IWL_SCAN_DWELL_ACTIVE; - cmd->passive_dwell = IWL_SCAN_DWELL_PASSIVE; - cmd->extended_dwell = IWL_SCAN_DWELL_EXTENDED; + cmd->v1.active_dwell = IWL_SCAN_DWELL_ACTIVE; + cmd->v1.passive_dwell = IWL_SCAN_DWELL_PASSIVE; + cmd->v1.extended_dwell = IWL_SCAN_DWELL_EXTENDED; } - cmd->fragmented_dwell = IWL_SCAN_DWELL_FRAGMENTED; + cmd->v1.fragmented_dwell = IWL_SCAN_DWELL_FRAGMENTED; if (iwl_mvm_has_new_tx_api(mvm)) { cmd->v6.scan_priority = cpu_to_le32(IWL_SCAN_PRIORITY_EXT_6); - cmd->v6.max_out_time[0] = cpu_to_le32(timing->max_out_time); - cmd->v6.suspend_time[0] = cpu_to_le32(timing->suspend_time); + cmd->v6.max_out_time[SCAN_LB_LMAC_IDX] = + cpu_to_le32(timing->max_out_time); + cmd->v6.suspend_time[SCAN_LB_LMAC_IDX] = + cpu_to_le32(timing->suspend_time); if (iwl_mvm_is_cdb_supported(mvm)) { - cmd->v6.max_out_time[1] = + cmd->v6.max_out_time[SCAN_HB_LMAC_IDX] = cpu_to_le32(timing->max_out_time); - cmd->v6.suspend_time[1] = + cmd->v6.suspend_time[SCAN_HB_LMAC_IDX] = cpu_to_le32(timing->suspend_time); } } else { @@ -1102,11 +1147,6 @@ static void iwl_mvm_scan_umac_dwell(stru cmd->v1.scan_priority = cpu_to_le32(IWL_SCAN_PRIORITY_EXT_6); } - - if (iwl_mvm_is_regular_scan(params)) - cmd->ooc_priority = cpu_to_le32(IWL_SCAN_PRIORITY_EXT_6); - else - cmd->ooc_priority = cpu_to_le32(IWL_SCAN_PRIORITY_EXT_2); } static void @@ -1178,8 +1218,7 @@ static int iwl_mvm_scan_umac(struct iwl_ int type) { struct iwl_scan_req_umac *cmd = mvm->scan_cmd; - void *cmd_data = iwl_mvm_has_new_tx_api(mvm) ? - (void *)&cmd->v6.data : (void *)&cmd->v1.data; + void *cmd_data = iwl_mvm_get_scan_req_umac_data(mvm); struct iwl_scan_req_umac_tail *sec_part = cmd_data + sizeof(struct iwl_scan_channel_cfg_umac) * mvm->fw->ucode_capa.n_scan_channels; @@ -1216,7 +1255,10 @@ static int iwl_mvm_scan_umac(struct iwl_ IWL_SCAN_CHANNEL_FLAG_EBS_ACCURATE | IWL_SCAN_CHANNEL_FLAG_CACHE_ADD; - if (iwl_mvm_has_new_tx_api(mvm)) { + if (iwl_mvm_is_adaptive_dwell_supported(mvm)) { + cmd->v7.channel_flags = channel_flags; + cmd->v7.n_channels = params->n_channels; + } else if (iwl_mvm_has_new_tx_api(mvm)) { cmd->v6.channel_flags = channel_flags; cmd->v6.n_channels = params->n_channels; } else { @@ -1661,8 +1703,10 @@ int iwl_mvm_scan_size(struct iwl_mvm *mv { int base_size = IWL_SCAN_REQ_UMAC_SIZE_V1; - if (iwl_mvm_has_new_tx_api(mvm)) - base_size = IWL_SCAN_REQ_UMAC_SIZE; + if (iwl_mvm_is_adaptive_dwell_supported(mvm)) + base_size = IWL_SCAN_REQ_UMAC_SIZE_V7; + else if (iwl_mvm_has_new_tx_api(mvm)) + base_size = IWL_SCAN_REQ_UMAC_SIZE_V6; if (fw_has_capa(&mvm->fw->ucode_capa, IWL_UCODE_TLV_CAPA_UMAC_SCAN)) return base_size + Patches currently in stable-queue which might be from luciano.coelho(a)intel.com are queue-4.14/iwlwifi-fix-firmware-names-for-9000-and-a000-series-hw.patch queue-4.14/iwlwifi-fix-wrong-struct-for-a000-device.patch queue-4.14/iwlwifi-add-new-cards-for-8265-series.patch queue-4.14/iwlwifi-pcie-sort-ids-for-the-9000-series-for-easier-comparisons.patch queue-4.14/iwlwifi-fix-pci-ids-and-configuration-mapping-for-9000-series.patch queue-4.14/iwlwifi-add-new-cards-for-a000-series.patch queue-4.14/iwlwifi-mvm-support-version-7-of-the-scan_req_umac-fw-command.patch queue-4.14/iwlwifi-add-a-new-a000-device.patch queue-4.14/iwlwifi-add-new-cards-for-8260-series.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "iwlwifi: fix wrong struct for a000 device" 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 iwlwifi: fix wrong struct for a000 device 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: iwlwifi-fix-wrong-struct-for-a000-device.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 f7f5873bbd45a67d3097dfb55237ade2ad520184 Mon Sep 17 00:00:00 2001 From: Oren Givon <oren.givon(a)intel.com> Date: Mon, 28 Aug 2017 10:33:38 +0300 Subject: iwlwifi: fix wrong struct for a000 device From: Oren Givon <oren.givon(a)intel.com> commit f7f5873bbd45a67d3097dfb55237ade2ad520184 upstream. The PCI ID (0x2720, 0x0070) was set with the config struct iwla000_2ax_cfg_hr instead of iwla000_2ac_cfg_hr_cdb. Fixes: 175b87c69253 ("iwlwifi: add the new a000_2ax series") Signed-off-by: Oren Givon <oren.givon(a)intel.com> Signed-off-by: Luca Coelho <luciano.coelho(a)intel.com> Cc: Thomas Backlund <tmb(a)mageia.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/wireless/intel/iwlwifi/pcie/drv.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/net/wireless/intel/iwlwifi/pcie/drv.c +++ b/drivers/net/wireless/intel/iwlwifi/pcie/drv.c @@ -576,7 +576,7 @@ static const struct pci_device_id iwl_hw {IWL_PCI_DEVICE(0x2720, 0x0000, iwla000_2ax_cfg_hr)}, {IWL_PCI_DEVICE(0x34F0, 0x0070, iwla000_2ax_cfg_hr)}, {IWL_PCI_DEVICE(0x2720, 0x0078, iwla000_2ax_cfg_hr)}, - {IWL_PCI_DEVICE(0x2720, 0x0070, iwla000_2ax_cfg_hr)}, + {IWL_PCI_DEVICE(0x2720, 0x0070, iwla000_2ac_cfg_hr_cdb)}, {IWL_PCI_DEVICE(0x2720, 0x1080, iwla000_2ax_cfg_hr)}, #endif /* CONFIG_IWLMVM */ Patches currently in stable-queue which might be from oren.givon(a)intel.com are queue-4.14/iwlwifi-fix-wrong-struct-for-a000-device.patch queue-4.14/iwlwifi-add-a-new-a000-device.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "iwlwifi: fix PCI IDs and configuration mapping for 9000 series" 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 iwlwifi: fix PCI IDs and configuration mapping for 9000 series 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: iwlwifi-fix-pci-ids-and-configuration-mapping-for-9000-series.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 dbc89253a7e15f8f031fb1eeb956de91204655e3 Mon Sep 17 00:00:00 2001 From: Luca Coelho <luciano.coelho(a)intel.com> Date: Wed, 15 Nov 2017 18:28:04 +0200 Subject: iwlwifi: fix PCI IDs and configuration mapping for 9000 series From: Luca Coelho <luciano.coelho(a)intel.com> commit dbc89253a7e15f8f031fb1eeb956de91204655e3 upstream. A lot of PCI IDs were missing and there were some problems with the configuration and firmware selection for devices on the 9000 series. Fix the firmware selection by adding files for the B-steps; add configuration for some integrated devices; and add a bunch of PCI IDs (mostly for integrated devices) that were missing from the driver's list. Without this patch, a lot of devices will not be recognized or will try to load the wrong firmware file. Signed-off-by: Luca Coelho <luciano.coelho(a)intel.com> Cc: Thomas Backlund <tmb(a)mageia.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/wireless/intel/iwlwifi/cfg/9000.c | 67 +++++++++++- drivers/net/wireless/intel/iwlwifi/iwl-config.h | 5 drivers/net/wireless/intel/iwlwifi/pcie/drv.c | 132 ++++++++++++++++++------ 3 files changed, 170 insertions(+), 34 deletions(-) --- a/drivers/net/wireless/intel/iwlwifi/cfg/9000.c +++ b/drivers/net/wireless/intel/iwlwifi/cfg/9000.c @@ -72,12 +72,15 @@ #define IWL9000_SMEM_OFFSET 0x400000 #define IWL9000_SMEM_LEN 0x68000 -#define IWL9000_FW_PRE "iwlwifi-9000-pu-a0-jf-a0-" +#define IWL9000A_FW_PRE "iwlwifi-9000-pu-a0-jf-a0-" +#define IWL9000B_FW_PRE "iwlwifi-9000-pu-b0-jf-b0-" #define IWL9000RFB_FW_PRE "iwlwifi-9000-pu-a0-jf-b0-" #define IWL9260A_FW_PRE "iwlwifi-9260-th-a0-jf-a0-" #define IWL9260B_FW_PRE "iwlwifi-9260-th-b0-jf-b0-" -#define IWL9000_MODULE_FIRMWARE(api) \ - IWL9000_FW_PRE "-" __stringify(api) ".ucode" +#define IWL9000A_MODULE_FIRMWARE(api) \ + IWL9000A_FW_PRE __stringify(api) ".ucode" +#define IWL9000B_MODULE_FIRMWARE(api) \ + IWL9000B_FW_PRE __stringify(api) ".ucode" #define IWL9000RFB_MODULE_FIRMWARE(api) \ IWL9000RFB_FW_PRE __stringify(api) ".ucode" #define IWL9260A_MODULE_FIRMWARE(api) \ @@ -193,7 +196,48 @@ const struct iwl_cfg iwl9460_2ac_cfg = { .nvm_ver = IWL9000_NVM_VERSION, .nvm_calib_ver = IWL9000_TX_POWER_VERSION, .max_ht_ampdu_exponent = IEEE80211_HT_MAX_AMPDU_64K, +}; + +const struct iwl_cfg iwl9460_2ac_cfg_soc = { + .name = "Intel(R) Dual Band Wireless AC 9460", + .fw_name_pre = IWL9000A_FW_PRE, + .fw_name_pre_b_or_c_step = IWL9000B_FW_PRE, + .fw_name_pre_rf_next_step = IWL9000RFB_FW_PRE, + IWL_DEVICE_9000, + .ht_params = &iwl9000_ht_params, + .nvm_ver = IWL9000_NVM_VERSION, + .nvm_calib_ver = IWL9000_TX_POWER_VERSION, + .max_ht_ampdu_exponent = IEEE80211_HT_MAX_AMPDU_64K, .integrated = true, + .soc_latency = 5000, +}; + +const struct iwl_cfg iwl9461_2ac_cfg_soc = { + .name = "Intel(R) Dual Band Wireless AC 9461", + .fw_name_pre = IWL9000A_FW_PRE, + .fw_name_pre_b_or_c_step = IWL9000B_FW_PRE, + .fw_name_pre_rf_next_step = IWL9000RFB_FW_PRE, + IWL_DEVICE_9000, + .ht_params = &iwl9000_ht_params, + .nvm_ver = IWL9000_NVM_VERSION, + .nvm_calib_ver = IWL9000_TX_POWER_VERSION, + .max_ht_ampdu_exponent = IEEE80211_HT_MAX_AMPDU_64K, + .integrated = true, + .soc_latency = 5000, +}; + +const struct iwl_cfg iwl9462_2ac_cfg_soc = { + .name = "Intel(R) Dual Band Wireless AC 9462", + .fw_name_pre = IWL9000A_FW_PRE, + .fw_name_pre_b_or_c_step = IWL9000B_FW_PRE, + .fw_name_pre_rf_next_step = IWL9000RFB_FW_PRE, + IWL_DEVICE_9000, + .ht_params = &iwl9000_ht_params, + .nvm_ver = IWL9000_NVM_VERSION, + .nvm_calib_ver = IWL9000_TX_POWER_VERSION, + .max_ht_ampdu_exponent = IEEE80211_HT_MAX_AMPDU_64K, + .integrated = true, + .soc_latency = 5000, }; const struct iwl_cfg iwl9560_2ac_cfg = { @@ -205,10 +249,23 @@ const struct iwl_cfg iwl9560_2ac_cfg = { .nvm_ver = IWL9000_NVM_VERSION, .nvm_calib_ver = IWL9000_TX_POWER_VERSION, .max_ht_ampdu_exponent = IEEE80211_HT_MAX_AMPDU_64K, - .integrated = true, }; -MODULE_FIRMWARE(IWL9000_MODULE_FIRMWARE(IWL9000_UCODE_API_MAX)); +const struct iwl_cfg iwl9560_2ac_cfg_soc = { + .name = "Intel(R) Dual Band Wireless AC 9560", + .fw_name_pre = IWL9000A_FW_PRE, + .fw_name_pre_b_or_c_step = IWL9000B_FW_PRE, + .fw_name_pre_rf_next_step = IWL9000RFB_FW_PRE, + IWL_DEVICE_9000, + .ht_params = &iwl9000_ht_params, + .nvm_ver = IWL9000_NVM_VERSION, + .nvm_calib_ver = IWL9000_TX_POWER_VERSION, + .max_ht_ampdu_exponent = IEEE80211_HT_MAX_AMPDU_64K, + .integrated = true, + .soc_latency = 5000, +}; +MODULE_FIRMWARE(IWL9000A_MODULE_FIRMWARE(IWL9000_UCODE_API_MAX)); +MODULE_FIRMWARE(IWL9000B_MODULE_FIRMWARE(IWL9000_UCODE_API_MAX)); MODULE_FIRMWARE(IWL9000RFB_MODULE_FIRMWARE(IWL9000_UCODE_API_MAX)); MODULE_FIRMWARE(IWL9260A_MODULE_FIRMWARE(IWL9000_UCODE_API_MAX)); MODULE_FIRMWARE(IWL9260B_MODULE_FIRMWARE(IWL9000_UCODE_API_MAX)); --- a/drivers/net/wireless/intel/iwlwifi/iwl-config.h +++ b/drivers/net/wireless/intel/iwlwifi/iwl-config.h @@ -364,6 +364,7 @@ struct iwl_cfg { u32 dccm2_len; u32 smem_offset; u32 smem_len; + u32 soc_latency; u16 nvm_ver; u16 nvm_calib_ver; u16 rx_with_siso_diversity:1, @@ -471,6 +472,10 @@ extern const struct iwl_cfg iwl9260_2ac_ extern const struct iwl_cfg iwl9270_2ac_cfg; extern const struct iwl_cfg iwl9460_2ac_cfg; extern const struct iwl_cfg iwl9560_2ac_cfg; +extern const struct iwl_cfg iwl9460_2ac_cfg_soc; +extern const struct iwl_cfg iwl9461_2ac_cfg_soc; +extern const struct iwl_cfg iwl9462_2ac_cfg_soc; +extern const struct iwl_cfg iwl9560_2ac_cfg_soc; extern const struct iwl_cfg iwla000_2ac_cfg_hr; extern const struct iwl_cfg iwla000_2ac_cfg_hr_cdb; extern const struct iwl_cfg iwla000_2ac_cfg_jf; --- a/drivers/net/wireless/intel/iwlwifi/pcie/drv.c +++ b/drivers/net/wireless/intel/iwlwifi/pcie/drv.c @@ -533,47 +533,121 @@ static const struct pci_device_id iwl_hw {IWL_PCI_DEVICE(0x2526, 0x0238, iwl9560_2ac_cfg)}, {IWL_PCI_DEVICE(0x2526, 0x023C, iwl9560_2ac_cfg)}, {IWL_PCI_DEVICE(0x2526, 0x0260, iwl9460_2ac_cfg)}, + {IWL_PCI_DEVICE(0x2526, 0x0264, iwl9461_2ac_cfg_soc)}, {IWL_PCI_DEVICE(0x2526, 0x02A0, iwl9460_2ac_cfg)}, {IWL_PCI_DEVICE(0x2526, 0x02A4, iwl9460_2ac_cfg)}, + {IWL_PCI_DEVICE(0x2526, 0x1010, iwl9260_2ac_cfg)}, {IWL_PCI_DEVICE(0x2526, 0x1030, iwl9560_2ac_cfg)}, + {IWL_PCI_DEVICE(0x2526, 0x1210, iwl9260_2ac_cfg)}, {IWL_PCI_DEVICE(0x2526, 0x1410, iwl9270_2ac_cfg)}, - {IWL_PCI_DEVICE(0x2526, 0x1420, iwl9460_2ac_cfg)}, + {IWL_PCI_DEVICE(0x2526, 0x1420, iwl9460_2ac_cfg_soc)}, {IWL_PCI_DEVICE(0x2526, 0x1610, iwl9270_2ac_cfg)}, {IWL_PCI_DEVICE(0x2526, 0x4010, iwl9260_2ac_cfg)}, {IWL_PCI_DEVICE(0x2526, 0x4030, iwl9560_2ac_cfg)}, {IWL_PCI_DEVICE(0x2526, 0x40A4, iwl9460_2ac_cfg)}, {IWL_PCI_DEVICE(0x2526, 0xA014, iwl9260_2ac_cfg)}, + {IWL_PCI_DEVICE(0x2526, 0x42A4, iwl9462_2ac_cfg_soc)}, {IWL_PCI_DEVICE(0x271B, 0x0010, iwl9160_2ac_cfg)}, {IWL_PCI_DEVICE(0x271B, 0x0014, iwl9160_2ac_cfg)}, {IWL_PCI_DEVICE(0x271B, 0x0210, iwl9160_2ac_cfg)}, - {IWL_PCI_DEVICE(0x30DC, 0x0060, iwl9460_2ac_cfg)}, - {IWL_PCI_DEVICE(0x31DC, 0x0030, iwl9560_2ac_cfg)}, - {IWL_PCI_DEVICE(0x31DC, 0x0034, iwl9560_2ac_cfg)}, - {IWL_PCI_DEVICE(0x31DC, 0x0038, iwl9560_2ac_cfg)}, - {IWL_PCI_DEVICE(0x31DC, 0x003C, iwl9560_2ac_cfg)}, - {IWL_PCI_DEVICE(0x31DC, 0x0060, iwl9460_2ac_cfg)}, - {IWL_PCI_DEVICE(0x9DF0, 0x0000, iwl9460_2ac_cfg)}, - {IWL_PCI_DEVICE(0x9DF0, 0x0010, iwl9460_2ac_cfg)}, - {IWL_PCI_DEVICE(0x9DF0, 0x0030, iwl9560_2ac_cfg)}, - {IWL_PCI_DEVICE(0x9DF0, 0x0034, iwl9560_2ac_cfg)}, - {IWL_PCI_DEVICE(0x9DF0, 0x0038, iwl9560_2ac_cfg)}, - {IWL_PCI_DEVICE(0x9DF0, 0x003C, iwl9560_2ac_cfg)}, - {IWL_PCI_DEVICE(0x9DF0, 0x0060, iwl9460_2ac_cfg)}, - {IWL_PCI_DEVICE(0x9DF0, 0x0210, iwl9460_2ac_cfg)}, - {IWL_PCI_DEVICE(0x9DF0, 0x0310, iwl9460_2ac_cfg)}, - {IWL_PCI_DEVICE(0x9DF0, 0x0410, iwl9460_2ac_cfg)}, - {IWL_PCI_DEVICE(0x9DF0, 0x0510, iwl9460_2ac_cfg)}, - {IWL_PCI_DEVICE(0x9DF0, 0x0610, iwl9460_2ac_cfg)}, - {IWL_PCI_DEVICE(0x9DF0, 0x0710, iwl9460_2ac_cfg)}, - {IWL_PCI_DEVICE(0x9DF0, 0x0A10, iwl9460_2ac_cfg)}, - {IWL_PCI_DEVICE(0x9DF0, 0x2010, iwl9460_2ac_cfg)}, - {IWL_PCI_DEVICE(0x9DF0, 0x2A10, iwl9460_2ac_cfg)}, - {IWL_PCI_DEVICE(0xA370, 0x0030, iwl9560_2ac_cfg)}, - {IWL_PCI_DEVICE(0xA370, 0x0034, iwl9560_2ac_cfg)}, - {IWL_PCI_DEVICE(0xA370, 0x0038, iwl9560_2ac_cfg)}, - {IWL_PCI_DEVICE(0xA370, 0x003C, iwl9560_2ac_cfg)}, - {IWL_PCI_DEVICE(0xA370, 0x0060, iwl9460_2ac_cfg)}, - {IWL_PCI_DEVICE(0xA370, 0x1030, iwl9560_2ac_cfg)}, + {IWL_PCI_DEVICE(0x271B, 0x0214, iwl9260_2ac_cfg)}, + {IWL_PCI_DEVICE(0x2720, 0x0034, iwl9560_2ac_cfg)}, + {IWL_PCI_DEVICE(0x2720, 0x0038, iwl9560_2ac_cfg)}, + {IWL_PCI_DEVICE(0x2720, 0x003C, iwl9560_2ac_cfg)}, + {IWL_PCI_DEVICE(0x2720, 0x0060, iwl9461_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x2720, 0x0064, iwl9461_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x2720, 0x00A0, iwl9462_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x2720, 0x00A4, iwl9462_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x2720, 0x0230, iwl9560_2ac_cfg)}, + {IWL_PCI_DEVICE(0x2720, 0x0234, iwl9560_2ac_cfg)}, + {IWL_PCI_DEVICE(0x2720, 0x0238, iwl9560_2ac_cfg)}, + {IWL_PCI_DEVICE(0x2720, 0x023C, iwl9560_2ac_cfg)}, + {IWL_PCI_DEVICE(0x2720, 0x0260, iwl9461_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x2720, 0x0264, iwl9461_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x2720, 0x02A0, iwl9462_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x2720, 0x02A4, iwl9462_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x2720, 0x4030, iwl9560_2ac_cfg)}, + {IWL_PCI_DEVICE(0x2720, 0x40A4, iwl9462_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x30DC, 0x0060, iwl9460_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x30DC, 0x0064, iwl9461_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x30DC, 0x00A0, iwl9462_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x30DC, 0x00A4, iwl9462_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x30DC, 0x0260, iwl9461_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x30DC, 0x0264, iwl9461_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x30DC, 0x02A0, iwl9462_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x30DC, 0x02A4, iwl9462_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x31DC, 0x0030, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x31DC, 0x0034, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x31DC, 0x0038, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x31DC, 0x003C, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x31DC, 0x0060, iwl9460_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x31DC, 0x0064, iwl9461_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x31DC, 0x00A0, iwl9462_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x31DC, 0x00A4, iwl9462_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x31DC, 0x0230, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x31DC, 0x0234, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x31DC, 0x0238, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x31DC, 0x023C, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x31DC, 0x0260, iwl9461_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x31DC, 0x0264, iwl9461_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x31DC, 0x02A0, iwl9462_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x31DC, 0x02A4, iwl9462_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x31DC, 0x4030, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x31DC, 0x4034, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x31DC, 0x40A4, iwl9462_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x34F0, 0x0030, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x34F0, 0x0034, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x34F0, 0x02A4, iwl9462_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x9DF0, 0x0000, iwl9460_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x9DF0, 0x0010, iwl9460_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x9DF0, 0x0030, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x9DF0, 0x0034, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x9DF0, 0x0038, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x9DF0, 0x003C, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x9DF0, 0x0060, iwl9460_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x9DF0, 0x0064, iwl9461_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x9DF0, 0x00A0, iwl9462_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x9DF0, 0x00A4, iwl9462_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x9DF0, 0x0210, iwl9460_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x9DF0, 0x0230, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x9DF0, 0x0234, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x9DF0, 0x0238, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x9DF0, 0x023C, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x9DF0, 0x0260, iwl9461_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x9DF0, 0x0264, iwl9461_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x9DF0, 0x02A0, iwl9462_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x9DF0, 0x02A4, iwl9462_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x9DF0, 0x0310, iwl9460_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x9DF0, 0x0410, iwl9460_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x9DF0, 0x0510, iwl9460_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x9DF0, 0x0610, iwl9460_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x9DF0, 0x0710, iwl9460_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x9DF0, 0x0A10, iwl9460_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x9DF0, 0x2010, iwl9460_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x9DF0, 0x2A10, iwl9460_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x9DF0, 0x4030, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x9DF0, 0x4034, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0x9DF0, 0x40A4, iwl9462_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0xA370, 0x0030, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0xA370, 0x0034, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0xA370, 0x0038, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0xA370, 0x003C, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0xA370, 0x0060, iwl9460_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0xA370, 0x0064, iwl9461_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0xA370, 0x00A0, iwl9462_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0xA370, 0x00A4, iwl9462_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0xA370, 0x0230, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0xA370, 0x0234, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0xA370, 0x0238, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0xA370, 0x023C, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0xA370, 0x0260, iwl9461_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0xA370, 0x0264, iwl9461_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0xA370, 0x02A0, iwl9462_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0xA370, 0x02A4, iwl9462_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0xA370, 0x1030, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0xA370, 0x4030, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0xA370, 0x4034, iwl9560_2ac_cfg_soc)}, + {IWL_PCI_DEVICE(0xA370, 0x40A4, iwl9462_2ac_cfg_soc)}, /* a000 Series */ {IWL_PCI_DEVICE(0x2720, 0x0A10, iwla000_2ac_cfg_hr_cdb)}, Patches currently in stable-queue which might be from luciano.coelho(a)intel.com are queue-4.14/iwlwifi-fix-firmware-names-for-9000-and-a000-series-hw.patch queue-4.14/iwlwifi-fix-wrong-struct-for-a000-device.patch queue-4.14/iwlwifi-add-new-cards-for-8265-series.patch queue-4.14/iwlwifi-pcie-sort-ids-for-the-9000-series-for-easier-comparisons.patch queue-4.14/iwlwifi-fix-pci-ids-and-configuration-mapping-for-9000-series.patch queue-4.14/iwlwifi-add-new-cards-for-a000-series.patch queue-4.14/iwlwifi-mvm-support-version-7-of-the-scan_req_umac-fw-command.patch queue-4.14/iwlwifi-add-a-new-a000-device.patch queue-4.14/iwlwifi-add-new-cards-for-8260-series.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "iwlwifi: add new cards for a000 series" 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 iwlwifi: add new cards for a000 series 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: iwlwifi-add-new-cards-for-a000-series.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 57b36f7fcb39c5eae8c1f463699f747af69643ba Mon Sep 17 00:00:00 2001 From: Ihab Zhaika <ihab.zhaika(a)intel.com> Date: Tue, 24 Oct 2017 17:04:24 +0300 Subject: iwlwifi: add new cards for a000 series From: Ihab Zhaika <ihab.zhaika(a)intel.com> commit 57b36f7fcb39c5eae8c1f463699f747af69643ba upstream. add four new PCI ID'S for a000 series Signed-off-by: Ihab Zhaika <ihab.zhaika(a)intel.com> Signed-off-by: Luca Coelho <luciano.coelho(a)intel.com> Cc: Thomas Backlund <tmb(a)mageia.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/wireless/intel/iwlwifi/pcie/drv.c | 5 +++++ 1 file changed, 5 insertions(+) --- a/drivers/net/wireless/intel/iwlwifi/pcie/drv.c +++ b/drivers/net/wireless/intel/iwlwifi/pcie/drv.c @@ -579,6 +579,11 @@ static const struct pci_device_id iwl_hw {IWL_PCI_DEVICE(0x2720, 0x0070, iwla000_2ac_cfg_hr_cdb)}, {IWL_PCI_DEVICE(0x2720, 0x0030, iwla000_2ac_cfg_hr_cdb)}, {IWL_PCI_DEVICE(0x2720, 0x1080, iwla000_2ax_cfg_hr)}, + {IWL_PCI_DEVICE(0x2720, 0x0090, iwla000_2ac_cfg_hr_cdb)}, + {IWL_PCI_DEVICE(0x2720, 0x0310, iwla000_2ac_cfg_hr_cdb)}, + {IWL_PCI_DEVICE(0x40C0, 0x0000, iwla000_2ax_cfg_hr)}, + {IWL_PCI_DEVICE(0x40C0, 0x0A10, iwla000_2ax_cfg_hr)}, + #endif /* CONFIG_IWLMVM */ {0} Patches currently in stable-queue which might be from ihab.zhaika(a)intel.com are queue-4.14/iwlwifi-add-new-cards-for-8265-series.patch queue-4.14/iwlwifi-add-new-cards-for-a000-series.patch queue-4.14/iwlwifi-add-new-cards-for-8260-series.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "iwlwifi: add new cards for 8265 series" 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 iwlwifi: add new cards for 8265 series 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: iwlwifi-add-new-cards-for-8265-series.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 7cddbef445631109bd530ce7cdacaa04ff0a62d1 Mon Sep 17 00:00:00 2001 From: Ihab Zhaika <ihab.zhaika(a)intel.com> Date: Tue, 24 Oct 2017 17:38:12 +0300 Subject: iwlwifi: add new cards for 8265 series From: Ihab Zhaika <ihab.zhaika(a)intel.com> commit 7cddbef445631109bd530ce7cdacaa04ff0a62d1 upstream. add two new PCI ID'S for 8265 series Signed-off-by: Ihab Zhaika <ihab.zhaika(a)intel.com> Signed-off-by: Luca Coelho <luciano.coelho(a)intel.com> Cc: Thomas Backlund <tmb(a)mageia.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/wireless/intel/iwlwifi/pcie/drv.c | 2 ++ 1 file changed, 2 insertions(+) --- a/drivers/net/wireless/intel/iwlwifi/pcie/drv.c +++ b/drivers/net/wireless/intel/iwlwifi/pcie/drv.c @@ -508,6 +508,8 @@ static const struct pci_device_id iwl_hw {IWL_PCI_DEVICE(0x24FD, 0x3E01, iwl8275_2ac_cfg)}, {IWL_PCI_DEVICE(0x24FD, 0x1012, iwl8275_2ac_cfg)}, {IWL_PCI_DEVICE(0x24FD, 0x0012, iwl8275_2ac_cfg)}, + {IWL_PCI_DEVICE(0x24FD, 0x0014, iwl8265_2ac_cfg)}, + {IWL_PCI_DEVICE(0x24FD, 0x9074, iwl8265_2ac_cfg)}, /* 9000 Series */ {IWL_PCI_DEVICE(0x2526, 0x0000, iwl9260_2ac_cfg)}, Patches currently in stable-queue which might be from ihab.zhaika(a)intel.com are queue-4.14/iwlwifi-add-new-cards-for-8265-series.patch queue-4.14/iwlwifi-add-new-cards-for-a000-series.patch queue-4.14/iwlwifi-add-new-cards-for-8260-series.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "iwlwifi: add new cards for 8260 series" 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 iwlwifi: add new cards for 8260 series 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: iwlwifi-add-new-cards-for-8260-series.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 d669fc2d42a43ee0abcf2396df6e9c5a124aa984 Mon Sep 17 00:00:00 2001 From: Ihab Zhaika <ihab.zhaika(a)intel.com> Date: Tue, 24 Oct 2017 17:36:43 +0300 Subject: iwlwifi: add new cards for 8260 series From: Ihab Zhaika <ihab.zhaika(a)intel.com> commit d669fc2d42a43ee0abcf2396df6e9c5a124aa984 upstream. add three new PCI ID'S for 8260 series Signed-off-by: Ihab Zhaika <ihab.zhaika(a)intel.com> Signed-off-by: Luca Coelho <luciano.coelho(a)intel.com> Cc: Thomas Backlund <tmb(a)mageia.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/wireless/intel/iwlwifi/pcie/drv.c | 3 +++ 1 file changed, 3 insertions(+) --- a/drivers/net/wireless/intel/iwlwifi/pcie/drv.c +++ b/drivers/net/wireless/intel/iwlwifi/pcie/drv.c @@ -465,6 +465,8 @@ static const struct pci_device_id iwl_hw {IWL_PCI_DEVICE(0x24F3, 0x9110, iwl8260_2ac_cfg)}, {IWL_PCI_DEVICE(0x24F4, 0x8030, iwl8260_2ac_cfg)}, {IWL_PCI_DEVICE(0x24F4, 0x9030, iwl8260_2ac_cfg)}, + {IWL_PCI_DEVICE(0x24F4, 0xC030, iwl8260_2ac_cfg)}, + {IWL_PCI_DEVICE(0x24F4, 0xD030, iwl8260_2ac_cfg)}, {IWL_PCI_DEVICE(0x24F3, 0x8130, iwl8260_2ac_cfg)}, {IWL_PCI_DEVICE(0x24F3, 0x9130, iwl8260_2ac_cfg)}, {IWL_PCI_DEVICE(0x24F3, 0x8132, iwl8260_2ac_cfg)}, @@ -483,6 +485,7 @@ static const struct pci_device_id iwl_hw {IWL_PCI_DEVICE(0x24F3, 0x0950, iwl8260_2ac_cfg)}, {IWL_PCI_DEVICE(0x24F3, 0x0930, iwl8260_2ac_cfg)}, {IWL_PCI_DEVICE(0x24F3, 0x0000, iwl8265_2ac_cfg)}, + {IWL_PCI_DEVICE(0x24F3, 0x4010, iwl8260_2ac_cfg)}, {IWL_PCI_DEVICE(0x24FD, 0x0010, iwl8265_2ac_cfg)}, {IWL_PCI_DEVICE(0x24FD, 0x0110, iwl8265_2ac_cfg)}, {IWL_PCI_DEVICE(0x24FD, 0x1110, iwl8265_2ac_cfg)}, Patches currently in stable-queue which might be from ihab.zhaika(a)intel.com are queue-4.14/iwlwifi-add-new-cards-for-8265-series.patch queue-4.14/iwlwifi-add-new-cards-for-a000-series.patch queue-4.14/iwlwifi-add-new-cards-for-8260-series.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "iwlwifi: add a new a000 device" 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 iwlwifi: add a new a000 device 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: iwlwifi-add-a-new-a000-device.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 d048b36b9654c4e0cf0d3576be2d1ed2a3084c6f Mon Sep 17 00:00:00 2001 From: Oren Givon <oren.givon(a)intel.com> Date: Thu, 31 Aug 2017 13:15:09 +0300 Subject: iwlwifi: add a new a000 device From: Oren Givon <oren.givon(a)intel.com> commit d048b36b9654c4e0cf0d3576be2d1ed2a3084c6f upstream. Add a new a000 device with PCI ID (0x2720, 0x0030). Signed-off-by: Oren Givon <oren.givon(a)intel.com> Signed-off-by: Luca Coelho <luciano.coelho(a)intel.com> Cc: Thomas Backlund <tmb(a)mageia.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/wireless/intel/iwlwifi/pcie/drv.c | 1 + 1 file changed, 1 insertion(+) --- a/drivers/net/wireless/intel/iwlwifi/pcie/drv.c +++ b/drivers/net/wireless/intel/iwlwifi/pcie/drv.c @@ -577,6 +577,7 @@ static const struct pci_device_id iwl_hw {IWL_PCI_DEVICE(0x34F0, 0x0070, iwla000_2ax_cfg_hr)}, {IWL_PCI_DEVICE(0x2720, 0x0078, iwla000_2ax_cfg_hr)}, {IWL_PCI_DEVICE(0x2720, 0x0070, iwla000_2ac_cfg_hr_cdb)}, + {IWL_PCI_DEVICE(0x2720, 0x0030, iwla000_2ac_cfg_hr_cdb)}, {IWL_PCI_DEVICE(0x2720, 0x1080, iwla000_2ax_cfg_hr)}, #endif /* CONFIG_IWLMVM */ Patches currently in stable-queue which might be from oren.givon(a)intel.com are queue-4.14/iwlwifi-fix-wrong-struct-for-a000-device.patch queue-4.14/iwlwifi-add-a-new-a000-device.patch

7 years, 5 months

1
0
0 0

Re: [Linux-stable-mirror] [PATCH] Ensure that the SCSI error handler gets woken up

by Pavel Tikhomirov

Sorry, missed the thread, resending. 1-st, Stuart - thanks for adding me to CC, 2-nd Bart - no idea why you didn't? =) > If scsi_eh_scmd_add() is called concurrently with scsi_host_queue_ready() > while shost->host_blocked > 0 then it can happen that neither function > wakes up the SCSI error handler. Fix this by making every function that > decreases the host_busy counter to wake up the error handler if necessary. Bart, you've added a comment to my initial patch() about performance, let me quote it here: > An important achievement of the scsi-mq code was removal of all > spin_lock_irq(shost->host_lock) statements from the hot path. The above > changes will have a significant negative performance impact, especially if > multiple LUNs associated with the same SCSI host are involved. Can the > reported race be fixed without slowing down the hot path significantly? I > think that both adding spin lock or smp_mb() calls in the hot path will > have a significant negative performance impact. These was a tricky question so I had no immediate answer. Here is the one: a) We need to check if scsi_eh_wakeup needs to wake up error handler thread in every place where we change host_busy. Else we have a chance that these change will break the wake up check in other existing places and will lead to deadlock. b) If we have several variables and change them (one different variable in in different thread) and after that we want to check the joint state of these variables, we sould surely have some kind of memory barriers to have a consistent state at some point. c) We already have spinlocks in scsi_schedule_eh, scsi_eh_scmd_add and scsi_device_unbusy, so it seems the good thing to reuse them for new checks too. I don't see another way to fix these problem. Your patch puts spinlocks under check which should itself be under spinlock, and breaks the initial fix (see Stuart's comment that the problem still reproduces). And you does _not_ answer your own question. > > Reported-by: Pavel Tikhomirov <ptikhomirov@xxxxxxxxxxxxx> > Fixes: commit 746650160866 ("scsi: convert host_busy to atomic_t") > Signed-off-by: Bart Van Assche <bart.vanassche@xxxxxxx> As your patch is based on my initial patch (https://patchwork.kernel.org/patch/9938919/), when all problems will be resolved with it, can you please add here: Signed-off-by: Pavel Tikhomirov <ptikhomirov(a)virtuozzo.com> > Cc: Konstantin Khorenko <khorenko@xxxxxxxxxxxxx> > Cc: Stuart Hayes <stuart.w.hayes@xxxxxxxxx> > Cc: Christoph Hellwig <hch@xxxxxx> > Cc: Hannes Reinecke <hare@xxxxxxxx> > Cc: Johannes Thumshirn <jthumshirn@xxxxxxx> > Cc: <stable@xxxxxxxxxxxxxxx> > --- > drivers/scsi/scsi_error.c | 3 ++- > drivers/scsi/scsi_lib.c | 22 ++++++++++++++-------- > 2 files changed, 16 insertions(+), 9 deletions(-) > > diff --git a/drivers/scsi/scsi_error.c b/drivers/scsi/scsi_error.c > index 5e89049e9b4e..f7f014c755d7 100644 > --- a/drivers/scsi/scsi_error.c > +++ b/drivers/scsi/scsi_error.c > @@ -61,9 +61,10 @@ static int scsi_eh_try_stu(struct scsi_cmnd *scmd); > static int scsi_try_to_abort_cmd(struct scsi_host_template *, > struct scsi_cmnd *); > > -/* called with shost->host_lock held */ > void scsi_eh_wakeup(struct Scsi_Host *shost) > { > + lockdep_assert_held(shost->host_lock); > + > if (atomic_read(&shost->host_busy) == shost->host_failed) { > trace_scsi_eh_wakeup(shost); > wake_up_process(shost->ehandler); I also think these hunk is just an additional precaution and should be in separate patch. > diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c > index 1e05e1885ac8..abd37d77af2d 100644 > --- a/drivers/scsi/scsi_lib.c > +++ b/drivers/scsi/scsi_lib.c > @@ -318,22 +318,28 @@ static void scsi_init_cmd_errh(struct scsi_cmnd *cmd) > cmd->cmd_len = scsi_command_size(cmd->cmnd); > } > > -void scsi_device_unbusy(struct scsi_device *sdev) > +static void scsi_dec_host_busy(struct Scsi_Host *shost) > { > - struct Scsi_Host *shost = sdev->host; > - struct scsi_target *starget = scsi_target(sdev); > unsigned long flags; > > atomic_dec(&shost->host_busy); > - if (starget->can_queue > 0) > - atomic_dec(&starget->target_busy); > - > if (unlikely(scsi_host_in_recovery(shost) && > (shost->host_failed || shost->host_eh_scheduled))) { As I've wrote above you do wrong locking here in scsi_dec_host_busy. Note that the above check reads host_failed and can load host_failed before host_busy is decremented due to reordering. > spin_lock_irqsave(shost->host_lock, flags); > scsi_eh_wakeup(shost); > spin_unlock_irqrestore(shost->host_lock, flags); > } > +} > + > +void scsi_device_unbusy(struct scsi_device *sdev) > +{ > + struct Scsi_Host *shost = sdev->host; > + struct scsi_target *starget = scsi_target(sdev); > + > + scsi_dec_host_busy(shost); > + > + if (starget->can_queue > 0) > + atomic_dec(&starget->target_busy); > > atomic_dec(&sdev->device_busy); > } > @@ -1532,7 +1538,7 @@ static inline int scsi_host_queue_ready(struct request_queue *q, > list_add_tail(&sdev->starved_entry, &shost->starved_list); > spin_unlock_irq(shost->host_lock); > out_dec: > - atomic_dec(&shost->host_busy); > + scsi_dec_host_busy(shost); > return 0; > } > > @@ -2020,7 +2026,7 @@ static blk_status_t scsi_queue_rq(struct blk_mq_hw_ctx *hctx, > return BLK_STS_OK; > > out_dec_host_busy: > - atomic_dec(&shost->host_busy); > + scsi_dec_host_busy(shost); > out_dec_target_busy: > if (scsi_target(sdev)->can_queue > 0) > atomic_dec(&scsi_target(sdev)->target_busy); > -- > 2.15.0 -- Best regards, Tikhomirov Pavel Software Developer, Virtuozzo.

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "PM / OPP: Add missing of_node_put(np)" 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 PM / OPP: Add missing of_node_put(np) 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: pm-opp-add-missing-of_node_put-np.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 7978db344719dab1e56d05e6fc04aaaddcde0a5e Mon Sep 17 00:00:00 2001 From: Tobias Jordan <Tobias.Jordan(a)elektrobit.com> Date: Wed, 4 Oct 2017 11:35:03 +0530 Subject: PM / OPP: Add missing of_node_put(np) From: Tobias Jordan <Tobias.Jordan(a)elektrobit.com> commit 7978db344719dab1e56d05e6fc04aaaddcde0a5e upstream. The for_each_available_child_of_node() loop in _of_add_opp_table_v2() doesn't drop the reference to "np" on errors. Fix that. Fixes: 274659029c9d (PM / OPP: Add support to parse "operating-points-v2" bindings) Signed-off-by: Tobias Jordan <Tobias.Jordan(a)elektrobit.com> [ VK: Improved commit log. ] Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org> Reviewed-by: Stephen Boyd <sboyd(a)codeaurora.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/base/power/opp/of.c | 1 + 1 file changed, 1 insertion(+) --- a/drivers/base/power/opp/of.c +++ b/drivers/base/power/opp/of.c @@ -348,6 +348,7 @@ static int _of_add_opp_table_v2(struct d if (ret) { dev_err(dev, "%s: Failed to add OPP, %d\n", __func__, ret); + of_node_put(np); goto free_table; } } Patches currently in stable-queue which might be from Tobias.Jordan(a)elektrobit.com are queue-4.9/pm-opp-add-missing-of_node_put-np.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "net/9p: Switch to wait_event_killable()" 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 net/9p: Switch to wait_event_killable() 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: net-9p-switch-to-wait_event_killable.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 9523feac272ccad2ad8186ba4fcc89103754de52 Mon Sep 17 00:00:00 2001 From: Tuomas Tynkkynen <tuomas(a)tuxera.com> Date: Wed, 6 Sep 2017 17:59:08 +0300 Subject: net/9p: Switch to wait_event_killable() From: Tuomas Tynkkynen <tuomas(a)tuxera.com> commit 9523feac272ccad2ad8186ba4fcc89103754de52 upstream. Because userspace gets Very Unhappy when calls like stat() and execve() return -EINTR on 9p filesystem mounts. For instance, when bash is looking in PATH for things to execute and some SIGCHLD interrupts stat(), bash can throw a spurious 'command not found' since it doesn't retry the stat(). In practice, hitting the problem is rare and needs a really slow/bogged down 9p server. Signed-off-by: Tuomas Tynkkynen <tuomas(a)tuxera.com> Signed-off-by: Al Viro <viro(a)zeniv.linux.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/9p/client.c | 3 +-- net/9p/trans_virtio.c | 13 ++++++------- 2 files changed, 7 insertions(+), 9 deletions(-) --- a/net/9p/client.c +++ b/net/9p/client.c @@ -749,8 +749,7 @@ p9_client_rpc(struct p9_client *c, int8_ } again: /* Wait for the response */ - err = wait_event_interruptible(*req->wq, - req->status >= REQ_STATUS_RCVD); + err = wait_event_killable(*req->wq, req->status >= REQ_STATUS_RCVD); /* * Make sure our req is coherent with regard to updates in other --- a/net/9p/trans_virtio.c +++ b/net/9p/trans_virtio.c @@ -286,8 +286,8 @@ req_retry: if (err == -ENOSPC) { chan->ring_bufs_avail = 0; spin_unlock_irqrestore(&chan->lock, flags); - err = wait_event_interruptible(*chan->vc_wq, - chan->ring_bufs_avail); + err = wait_event_killable(*chan->vc_wq, + chan->ring_bufs_avail); if (err == -ERESTARTSYS) return err; @@ -327,7 +327,7 @@ static int p9_get_mapped_pages(struct vi * Other zc request to finish here */ if (atomic_read(&vp_pinned) >= chan->p9_max_pages) { - err = wait_event_interruptible(vp_wq, + err = wait_event_killable(vp_wq, (atomic_read(&vp_pinned) < chan->p9_max_pages)); if (err == -ERESTARTSYS) return err; @@ -471,8 +471,8 @@ req_retry_pinned: if (err == -ENOSPC) { chan->ring_bufs_avail = 0; spin_unlock_irqrestore(&chan->lock, flags); - err = wait_event_interruptible(*chan->vc_wq, - chan->ring_bufs_avail); + err = wait_event_killable(*chan->vc_wq, + chan->ring_bufs_avail); if (err == -ERESTARTSYS) goto err_out; @@ -489,8 +489,7 @@ req_retry_pinned: virtqueue_kick(chan->vq); spin_unlock_irqrestore(&chan->lock, flags); p9_debug(P9_DEBUG_TRANS, "virtio request kicked\n"); - err = wait_event_interruptible(*req->wq, - req->status >= REQ_STATUS_RCVD); + err = wait_event_killable(*req->wq, req->status >= REQ_STATUS_RCVD); /* * Non kernel buffers are pinned, unpin them */ Patches currently in stable-queue which might be from tuomas(a)tuxera.com are queue-4.9/net-9p-switch-to-wait_event_killable.patch queue-4.9/fs-9p-compare-qid.path-in-v9fs_test_inode.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "fscrypt: lock mutex before checking for bounce page pool" 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 fscrypt: lock mutex before checking for bounce page pool 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: fscrypt-lock-mutex-before-checking-for-bounce-page-pool.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 a0b3bc855374c50b5ea85273553485af48caf2f7 Mon Sep 17 00:00:00 2001 From: Eric Biggers <ebiggers(a)google.com> Date: Sun, 29 Oct 2017 06:30:19 -0400 Subject: fscrypt: lock mutex before checking for bounce page pool From: Eric Biggers <ebiggers(a)google.com> commit a0b3bc855374c50b5ea85273553485af48caf2f7 upstream. fscrypt_initialize(), which allocates the global bounce page pool when an encrypted file is first accessed, uses "double-checked locking" to try to avoid locking fscrypt_init_mutex. However, it doesn't use any memory barriers, so it's theoretically possible for a thread to observe a bounce page pool which has not been fully initialized. This is a classic bug with "double-checked locking". While "only a theoretical issue" in the latest kernel, in pre-4.8 kernels the pointer that was checked was not even the last to be initialized, so it was easily possible for a crash (NULL pointer dereference) to happen. This was changed only incidentally by the large refactor to use fs/crypto/. Solve both problems in a trivial way that can easily be backported: just always take the mutex. It's theoretically less efficient, but it shouldn't be noticeable in practice as the mutex is only acquired very briefly once per encrypted file. Later I'd like to make this use a helper macro like DO_ONCE(). However, DO_ONCE() runs in atomic context, so we'd need to add a new macro that allows blocking. Signed-off-by: Eric Biggers <ebiggers(a)google.com> Signed-off-by: Theodore Ts'o <tytso(a)mit.edu> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/crypto/crypto.c | 3 --- 1 file changed, 3 deletions(-) --- a/fs/crypto/crypto.c +++ b/fs/crypto/crypto.c @@ -484,9 +484,6 @@ int fscrypt_initialize(void) { int i, res = -ENOMEM; - if (fscrypt_bounce_page_pool) - return 0; - mutex_lock(&fscrypt_init_mutex); if (fscrypt_bounce_page_pool) goto already_initialized; Patches currently in stable-queue which might be from ebiggers(a)google.com are queue-4.9/lib-mpi-call-cond_resched-from-mpi_powm-loop.patch queue-4.9/fscrypt-lock-mutex-before-checking-for-bounce-page-pool.patch queue-4.9/dm-bufio-fix-integer-overflow-when-limiting-maximum-cache-size.patch queue-4.9/libceph-don-t-warn-if-user-tries-to-add-invalid-key.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "PM / OPP: Add missing of_node_put(np)" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled PM / OPP: Add missing of_node_put(np) to the 4.4-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: pm-opp-add-missing-of_node_put-np.patch and it can be found in the queue-4.4 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 7978db344719dab1e56d05e6fc04aaaddcde0a5e Mon Sep 17 00:00:00 2001 From: Tobias Jordan <Tobias.Jordan(a)elektrobit.com> Date: Wed, 4 Oct 2017 11:35:03 +0530 Subject: PM / OPP: Add missing of_node_put(np) From: Tobias Jordan <Tobias.Jordan(a)elektrobit.com> commit 7978db344719dab1e56d05e6fc04aaaddcde0a5e upstream. The for_each_available_child_of_node() loop in _of_add_opp_table_v2() doesn't drop the reference to "np" on errors. Fix that. Fixes: 274659029c9d (PM / OPP: Add support to parse "operating-points-v2" bindings) Signed-off-by: Tobias Jordan <Tobias.Jordan(a)elektrobit.com> [ VK: Improved commit log. ] Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org> Reviewed-by: Stephen Boyd <sboyd(a)codeaurora.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/base/power/opp/core.c | 1 + 1 file changed, 1 insertion(+) --- a/drivers/base/power/opp/core.c +++ b/drivers/base/power/opp/core.c @@ -1205,6 +1205,7 @@ static int _of_add_opp_table_v2(struct d if (ret) { dev_err(dev, "%s: Failed to add OPP, %d\n", __func__, ret); + of_node_put(np); goto free_table; } } Patches currently in stable-queue which might be from Tobias.Jordan(a)elektrobit.com are queue-4.4/pm-opp-add-missing-of_node_put-np.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "net/9p: Switch to wait_event_killable()" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled net/9p: Switch to wait_event_killable() to the 4.4-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: net-9p-switch-to-wait_event_killable.patch and it can be found in the queue-4.4 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 9523feac272ccad2ad8186ba4fcc89103754de52 Mon Sep 17 00:00:00 2001 From: Tuomas Tynkkynen <tuomas(a)tuxera.com> Date: Wed, 6 Sep 2017 17:59:08 +0300 Subject: net/9p: Switch to wait_event_killable() From: Tuomas Tynkkynen <tuomas(a)tuxera.com> commit 9523feac272ccad2ad8186ba4fcc89103754de52 upstream. Because userspace gets Very Unhappy when calls like stat() and execve() return -EINTR on 9p filesystem mounts. For instance, when bash is looking in PATH for things to execute and some SIGCHLD interrupts stat(), bash can throw a spurious 'command not found' since it doesn't retry the stat(). In practice, hitting the problem is rare and needs a really slow/bogged down 9p server. Signed-off-by: Tuomas Tynkkynen <tuomas(a)tuxera.com> Signed-off-by: Al Viro <viro(a)zeniv.linux.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/9p/client.c | 3 +-- net/9p/trans_virtio.c | 13 ++++++------- 2 files changed, 7 insertions(+), 9 deletions(-) --- a/net/9p/client.c +++ b/net/9p/client.c @@ -749,8 +749,7 @@ p9_client_rpc(struct p9_client *c, int8_ } again: /* Wait for the response */ - err = wait_event_interruptible(*req->wq, - req->status >= REQ_STATUS_RCVD); + err = wait_event_killable(*req->wq, req->status >= REQ_STATUS_RCVD); /* * Make sure our req is coherent with regard to updates in other --- a/net/9p/trans_virtio.c +++ b/net/9p/trans_virtio.c @@ -290,8 +290,8 @@ req_retry: if (err == -ENOSPC) { chan->ring_bufs_avail = 0; spin_unlock_irqrestore(&chan->lock, flags); - err = wait_event_interruptible(*chan->vc_wq, - chan->ring_bufs_avail); + err = wait_event_killable(*chan->vc_wq, + chan->ring_bufs_avail); if (err == -ERESTARTSYS) return err; @@ -331,7 +331,7 @@ static int p9_get_mapped_pages(struct vi * Other zc request to finish here */ if (atomic_read(&vp_pinned) >= chan->p9_max_pages) { - err = wait_event_interruptible(vp_wq, + err = wait_event_killable(vp_wq, (atomic_read(&vp_pinned) < chan->p9_max_pages)); if (err == -ERESTARTSYS) return err; @@ -475,8 +475,8 @@ req_retry_pinned: if (err == -ENOSPC) { chan->ring_bufs_avail = 0; spin_unlock_irqrestore(&chan->lock, flags); - err = wait_event_interruptible(*chan->vc_wq, - chan->ring_bufs_avail); + err = wait_event_killable(*chan->vc_wq, + chan->ring_bufs_avail); if (err == -ERESTARTSYS) goto err_out; @@ -493,8 +493,7 @@ req_retry_pinned: virtqueue_kick(chan->vq); spin_unlock_irqrestore(&chan->lock, flags); p9_debug(P9_DEBUG_TRANS, "virtio request kicked\n"); - err = wait_event_interruptible(*req->wq, - req->status >= REQ_STATUS_RCVD); + err = wait_event_killable(*req->wq, req->status >= REQ_STATUS_RCVD); /* * Non kernel buffers are pinned, unpin them */ Patches currently in stable-queue which might be from tuomas(a)tuxera.com are queue-4.4/net-9p-switch-to-wait_event_killable.patch queue-4.4/fs-9p-compare-qid.path-in-v9fs_test_inode.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "fscrypt: lock mutex before checking for bounce page pool" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled fscrypt: lock mutex before checking for bounce page pool to the 4.4-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: fscrypt-lock-mutex-before-checking-for-bounce-page-pool.patch and it can be found in the queue-4.4 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 a0b3bc855374c50b5ea85273553485af48caf2f7 Mon Sep 17 00:00:00 2001 From: Eric Biggers <ebiggers(a)google.com> Date: Sun, 29 Oct 2017 06:30:19 -0400 Subject: fscrypt: lock mutex before checking for bounce page pool From: Eric Biggers <ebiggers(a)google.com> commit a0b3bc855374c50b5ea85273553485af48caf2f7 upstream. fscrypt_initialize(), which allocates the global bounce page pool when an encrypted file is first accessed, uses "double-checked locking" to try to avoid locking fscrypt_init_mutex. However, it doesn't use any memory barriers, so it's theoretically possible for a thread to observe a bounce page pool which has not been fully initialized. This is a classic bug with "double-checked locking". While "only a theoretical issue" in the latest kernel, in pre-4.8 kernels the pointer that was checked was not even the last to be initialized, so it was easily possible for a crash (NULL pointer dereference) to happen. This was changed only incidentally by the large refactor to use fs/crypto/. Solve both problems in a trivial way that can easily be backported: just always take the mutex. It's theoretically less efficient, but it shouldn't be noticeable in practice as the mutex is only acquired very briefly once per encrypted file. Later I'd like to make this use a helper macro like DO_ONCE(). However, DO_ONCE() runs in atomic context, so we'd need to add a new macro that allows blocking. Signed-off-by: Eric Biggers <ebiggers(a)google.com> Signed-off-by: Theodore Ts'o <tytso(a)mit.edu> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/ext4/crypto_key.c | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) --- a/fs/ext4/crypto_key.c +++ b/fs/ext4/crypto_key.c @@ -129,11 +129,9 @@ int ext4_get_encryption_info(struct inod if (ei->i_crypt_info) return 0; - if (!ext4_read_workqueue) { - res = ext4_init_crypto(); - if (res) - return res; - } + res = ext4_init_crypto(); + if (res) + return res; res = ext4_xattr_get(inode, EXT4_XATTR_INDEX_ENCRYPTION, EXT4_XATTR_NAME_ENCRYPTION_CONTEXT, Patches currently in stable-queue which might be from ebiggers(a)google.com are queue-4.4/lib-mpi-call-cond_resched-from-mpi_powm-loop.patch queue-4.4/fscrypt-lock-mutex-before-checking-for-bounce-page-pool.patch queue-4.4/dm-bufio-fix-integer-overflow-when-limiting-maximum-cache-size.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "ARM64: dts: meson-gxl: Add alternate ARM Trusted Firmware reserved memory zone" 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 ARM64: dts: meson-gxl: Add alternate ARM Trusted Firmware reserved memory zone 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: arm64-dts-meson-gxl-add-alternate-arm-trusted-firmware-reserved-memory-zone.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 4ee8e51b9edfe7845a094690a365c844e5a35b4b Mon Sep 17 00:00:00 2001 From: Neil Armstrong <narmstrong(a)baylibre.com> Date: Wed, 11 Oct 2017 17:23:12 +0200 Subject: ARM64: dts: meson-gxl: Add alternate ARM Trusted Firmware reserved memory zone From: Neil Armstrong <narmstrong(a)baylibre.com> commit 4ee8e51b9edfe7845a094690a365c844e5a35b4b upstream. This year, Amlogic updated the ARM Trusted Firmware reserved memory mapping for Meson GXL SoCs and products sold since May 2017 uses this alternate reserved memory mapping. But products had been sold using the previous mapping. This issue has been explained in [1] and a dynamic solution is yet to be found to avoid loosing another 3Mbytes of reservable memory. In the meantime, this patch adds this alternate memory zone only for the GXL and GXM SoCs since GXBB based new products stopped earlier. [1] http://lists.infradead.org/pipermail/linux-amlogic/2017-October/004860.html Fixes: bba8e3f42736 ("ARM64: dts: meson-gx: Add firmware reserved memory zones") Reported-by: Jerome Brunet <jbrunet(a)baylibre.com> Signed-off-by: Neil Armstrong <narmstrong(a)baylibre.com> Signed-off-by: Kevin Hilman <khilman(a)baylibre.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/arm64/boot/dts/amlogic/meson-gxl.dtsi | 8 ++++++++ 1 file changed, 8 insertions(+) --- a/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi +++ b/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi @@ -49,6 +49,14 @@ / { compatible = "amlogic,meson-gxl"; + + reserved-memory { + /* Alternate 3 MiB reserved for ARM Trusted Firmware (BL31) */ + secmon_reserved_alt: secmon@05000000 { + reg = <0x0 0x05000000 0x0 0x300000>; + no-map; + }; + }; }; &ethmac { Patches currently in stable-queue which might be from narmstrong(a)baylibre.com are queue-4.14/arm64-dts-meson-gxl-add-alternate-arm-trusted-firmware-reserved-memory-zone.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] [PATCH v4.9] PM / OPP: Add missing of_node_put(np)

by Viresh Kumar

From: Tobias Jordan <Tobias.Jordan(a)elektrobit.com> commit 7978db344719dab1e56d05e6fc04aaaddcde0a5e upstream. The for_each_available_child_of_node() loop in _of_add_opp_table_v2() doesn't drop the reference to "np" on errors. Fix that. Fixes: 274659029c9d (PM / OPP: Add support to parse "operating-points-v2" bindings) Cc: 4.9 <stable(a)vger.kernel.org> # 4.9 Signed-off-by: Tobias Jordan <Tobias.Jordan(a)elektrobit.com> [ VK: Improved commit log. ] Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org> Reviewed-by: Stephen Boyd <sboyd(a)codeaurora.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> --- drivers/base/power/opp/of.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/base/power/opp/of.c b/drivers/base/power/opp/of.c index 5552211e6fcd..af208884bbed 100644 --- a/drivers/base/power/opp/of.c +++ b/drivers/base/power/opp/of.c @@ -348,6 +348,7 @@ static int _of_add_opp_table_v2(struct device *dev, struct device_node *opp_np) if (ret) { dev_err(dev, "%s: Failed to add OPP, %d\n", __func__, ret); + of_node_put(np); goto free_table; } } -- 2.15.0.194.g9af6a3dea062

7 years, 5 months

2
1
0 0

[Linux-stable-mirror] Patch "mtd: nand: Fix writing mtdoops to nand flash." has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled mtd: nand: Fix writing mtdoops to nand flash. to the 3.18-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: mtd-nand-fix-writing-mtdoops-to-nand-flash.patch and it can be found in the queue-3.18 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 30863e38ebeb500a31cecee8096fb5002677dd9b Mon Sep 17 00:00:00 2001 From: Brent Taylor <motobud(a)gmail.com> Date: Mon, 30 Oct 2017 22:32:45 -0500 Subject: mtd: nand: Fix writing mtdoops to nand flash. From: Brent Taylor <motobud(a)gmail.com> commit 30863e38ebeb500a31cecee8096fb5002677dd9b upstream. When mtdoops calls mtd_panic_write(), it eventually calls panic_nand_write() in nand_base.c. In order to properly wait for the nand chip to be ready in panic_nand_wait(), the chip must first be selected. When using the atmel nand flash controller, a panic would occur due to a NULL pointer exception. Fixes: 2af7c6539931 ("mtd: Add panic_write for NAND flashes") Signed-off-by: Brent Taylor <motobud(a)gmail.com> Signed-off-by: Boris Brezillon <boris.brezillon(a)free-electrons.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/mtd/nand/nand_base.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) --- a/drivers/mtd/nand/nand_base.c +++ b/drivers/mtd/nand/nand_base.c @@ -2501,15 +2501,18 @@ static int panic_nand_write(struct mtd_i size_t *retlen, const uint8_t *buf) { struct nand_chip *chip = mtd->priv; + int chipnr = (int)(to >> chip->chip_shift); struct mtd_oob_ops ops; int ret; - /* Wait for the device to get ready */ - panic_nand_wait(mtd, chip, 400); - /* Grab the device */ panic_nand_get_device(chip, mtd, FL_WRITING); + chip->select_chip(mtd, chipnr); + + /* Wait for the device to get ready */ + panic_nand_wait(mtd, chip, 400); + ops.len = len; ops.datbuf = (uint8_t *)buf; ops.oobbuf = NULL; Patches currently in stable-queue which might be from motobud(a)gmail.com are queue-3.18/mtd-nand-fix-writing-mtdoops-to-nand-flash.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "net/9p: Switch to wait_event_killable()" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled net/9p: Switch to wait_event_killable() to the 3.18-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: net-9p-switch-to-wait_event_killable.patch and it can be found in the queue-3.18 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 9523feac272ccad2ad8186ba4fcc89103754de52 Mon Sep 17 00:00:00 2001 From: Tuomas Tynkkynen <tuomas(a)tuxera.com> Date: Wed, 6 Sep 2017 17:59:08 +0300 Subject: net/9p: Switch to wait_event_killable() From: Tuomas Tynkkynen <tuomas(a)tuxera.com> commit 9523feac272ccad2ad8186ba4fcc89103754de52 upstream. Because userspace gets Very Unhappy when calls like stat() and execve() return -EINTR on 9p filesystem mounts. For instance, when bash is looking in PATH for things to execute and some SIGCHLD interrupts stat(), bash can throw a spurious 'command not found' since it doesn't retry the stat(). In practice, hitting the problem is rare and needs a really slow/bogged down 9p server. Signed-off-by: Tuomas Tynkkynen <tuomas(a)tuxera.com> Signed-off-by: Al Viro <viro(a)zeniv.linux.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/9p/client.c | 3 +-- net/9p/trans_virtio.c | 13 ++++++------- 2 files changed, 7 insertions(+), 9 deletions(-) --- a/net/9p/client.c +++ b/net/9p/client.c @@ -753,8 +753,7 @@ p9_client_rpc(struct p9_client *c, int8_ } again: /* Wait for the response */ - err = wait_event_interruptible(*req->wq, - req->status >= REQ_STATUS_RCVD); + err = wait_event_killable(*req->wq, req->status >= REQ_STATUS_RCVD); /* * Make sure our req is coherent with regard to updates in other --- a/net/9p/trans_virtio.c +++ b/net/9p/trans_virtio.c @@ -292,8 +292,8 @@ req_retry: if (err == -ENOSPC) { chan->ring_bufs_avail = 0; spin_unlock_irqrestore(&chan->lock, flags); - err = wait_event_interruptible(*chan->vc_wq, - chan->ring_bufs_avail); + err = wait_event_killable(*chan->vc_wq, + chan->ring_bufs_avail); if (err == -ERESTARTSYS) return err; @@ -324,7 +324,7 @@ static int p9_get_mapped_pages(struct vi * Other zc request to finish here */ if (atomic_read(&vp_pinned) >= chan->p9_max_pages) { - err = wait_event_interruptible(vp_wq, + err = wait_event_killable(vp_wq, (atomic_read(&vp_pinned) < chan->p9_max_pages)); if (err == -ERESTARTSYS) return err; @@ -454,8 +454,8 @@ req_retry_pinned: if (err == -ENOSPC) { chan->ring_bufs_avail = 0; spin_unlock_irqrestore(&chan->lock, flags); - err = wait_event_interruptible(*chan->vc_wq, - chan->ring_bufs_avail); + err = wait_event_killable(*chan->vc_wq, + chan->ring_bufs_avail); if (err == -ERESTARTSYS) goto err_out; @@ -472,8 +472,7 @@ req_retry_pinned: virtqueue_kick(chan->vq); spin_unlock_irqrestore(&chan->lock, flags); p9_debug(P9_DEBUG_TRANS, "virtio request kicked\n"); - err = wait_event_interruptible(*req->wq, - req->status >= REQ_STATUS_RCVD); + err = wait_event_killable(*req->wq, req->status >= REQ_STATUS_RCVD); /* * Non kernel buffers are pinned, unpin them */ Patches currently in stable-queue which might be from tuomas(a)tuxera.com are queue-3.18/net-9p-switch-to-wait_event_killable.patch queue-3.18/fs-9p-compare-qid.path-in-v9fs_test_inode.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] [PATCH] mtd: nand: Fix writing mtdoops to nand flash

by motobud＠gmail.com

From: Brent Taylor <motobud(a)gmail.com> commit 30863e38ebeb500a31cecee8096fb5002677dd9b upstream. When mtdoops calls mtd_panic_write(), it eventually calls panic_nand_write() in nand_base.c. In order to properly wait for the nand chip to be ready in panic_nand_wait(), the chip must first be selected. When using the atmel nand flash controller, a panic would occur due to a NULL pointer exception. Fixes: 2af7c6539931 ("mtd: Add panic_write for NAND flashes") Cc: <stable(a)vger.kernel.org> # 4.4.x Cc: <stable(a)vger.kernel.org> # 3.18.x Signed-off-by: Brent Taylor <motobud(a)gmail.com> --- drivers/mtd/nand/nand_base.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c index 5b5c62712814..f0b95212c6b7 100644 --- a/drivers/mtd/nand/nand_base.c +++ b/drivers/mtd/nand/nand_base.c @@ -2501,15 +2501,18 @@ static int panic_nand_write(struct mtd_info *mtd, loff_t to, size_t len, size_t *retlen, const uint8_t *buf) { struct nand_chip *chip = mtd->priv; + int chipnr = (int)(to >> chip->chip_shift); struct mtd_oob_ops ops; int ret; - /* Wait for the device to get ready */ - panic_nand_wait(mtd, chip, 400); - /* Grab the device */ panic_nand_get_device(chip, mtd, FL_WRITING); + chip->select_chip(mtd, chipnr); + + /* Wait for the device to get ready */ + panic_nand_wait(mtd, chip, 400); + ops.len = len; ops.datbuf = (uint8_t *)buf; ops.oobbuf = NULL; -- 2.15.0

7 years, 5 months

2
1
0 0

[Linux-stable-mirror] [PATCH stable backport] net/9p: Switch to wait_event_killable()

by Tuomas Tynkkynen

commit 9523feac272ccad2ad8186ba4fcc89103754de52 upstream, with changes to net/9p/trans_xen.c dropped as that driver was only added in 4.12. Because userspace gets Very Unhappy when calls like stat() and execve() return -EINTR on 9p filesystem mounts. For instance, when bash is looking in PATH for things to execute and some SIGCHLD interrupts stat(), bash can throw a spurious 'command not found' since it doesn't retry the stat(). In practice, hitting the problem is rare and needs a really slow/bogged down 9p server. Cc: stable(a)vger.kernel.org Signed-off-by: Tuomas Tynkkynen <tuomas(a)tuxera.com> Signed-off-by: Al Viro <viro(a)zeniv.linux.org.uk> --- This backport applies to stable trees for 4.9 and below. --- net/9p/client.c | 3 +-- net/9p/trans_virtio.c | 13 ++++++------- 2 files changed, 7 insertions(+), 9 deletions(-) diff --git a/net/9p/client.c b/net/9p/client.c index cf129fec7329..1fd60190177e 100644 --- a/net/9p/client.c +++ b/net/9p/client.c @@ -749,8 +749,7 @@ p9_client_rpc(struct p9_client *c, int8_t type, const char *fmt, ...) } again: /* Wait for the response */ - err = wait_event_interruptible(*req->wq, - req->status >= REQ_STATUS_RCVD); + err = wait_event_killable(*req->wq, req->status >= REQ_STATUS_RCVD); /* * Make sure our req is coherent with regard to updates in other diff --git a/net/9p/trans_virtio.c b/net/9p/trans_virtio.c index f24b25c25106..f3a4efcf1456 100644 --- a/net/9p/trans_virtio.c +++ b/net/9p/trans_virtio.c @@ -286,8 +286,8 @@ p9_virtio_request(struct p9_client *client, struct p9_req_t *req) if (err == -ENOSPC) { chan->ring_bufs_avail = 0; spin_unlock_irqrestore(&chan->lock, flags); - err = wait_event_interruptible(*chan->vc_wq, - chan->ring_bufs_avail); + err = wait_event_killable(*chan->vc_wq, + chan->ring_bufs_avail); if (err == -ERESTARTSYS) return err; @@ -327,7 +327,7 @@ static int p9_get_mapped_pages(struct virtio_chan *chan, * Other zc request to finish here */ if (atomic_read(&vp_pinned) >= chan->p9_max_pages) { - err = wait_event_interruptible(vp_wq, + err = wait_event_killable(vp_wq, (atomic_read(&vp_pinned) < chan->p9_max_pages)); if (err == -ERESTARTSYS) return err; @@ -471,8 +471,8 @@ p9_virtio_zc_request(struct p9_client *client, struct p9_req_t *req, if (err == -ENOSPC) { chan->ring_bufs_avail = 0; spin_unlock_irqrestore(&chan->lock, flags); - err = wait_event_interruptible(*chan->vc_wq, - chan->ring_bufs_avail); + err = wait_event_killable(*chan->vc_wq, + chan->ring_bufs_avail); if (err == -ERESTARTSYS) goto err_out; @@ -489,8 +489,7 @@ p9_virtio_zc_request(struct p9_client *client, struct p9_req_t *req, virtqueue_kick(chan->vq); spin_unlock_irqrestore(&chan->lock, flags); p9_debug(P9_DEBUG_TRANS, "virtio request kicked\n"); - err = wait_event_interruptible(*req->wq, - req->status >= REQ_STATUS_RCVD); + err = wait_event_killable(*req->wq, req->status >= REQ_STATUS_RCVD); /* * Non kernel buffers are pinned, unpin them */ -- 2.15.0

7 years, 5 months

2
1
0 0

Re: [Linux-stable-mirror] [PATCH] ARM64: dts: meson-gxl: Add alternate ARM Trusted Firmware reserved memory zone

by Kevin Hilman

Greg, Neil Armstrong <narmstrong(a)baylibre.com> writes: > This year, Amlogic updated the ARM Trusted Firmware reserved memory mapping > for Meson GXL SoCs and products sold since May 2017 uses this alternate > reserved memory mapping. > But products had been sold using the previous mapping. > > This issue has been explained in [1] and a dynamic solution is yet to be > found to avoid loosing another 3Mbytes of reservable memory. > > In the meantime, this patch adds this alternate memory zone only for > the GXL and GXM SoCs since GXBB based new products stopped earlier. > > [1] http://lists.infradead.org/pipermail/linux-amlogic/2017-October/004860.html > > Fixes: bba8e3f42736 ("ARM64: dts: meson-gx: Add firmware reserved memory zones") > Reported-by: Jerome Brunet <jbrunet(a)baylibre.com> > Signed-off-by: Neil Armstrong <narmstrong(a)baylibre.com> I missed the Fixes tag on this one, but it's now commit 4ee8e51b9edf upstream. Please apply to stable v4.10+ Thanks, Kevin

7 years, 5 months

2
1
0 0

[Linux-stable-mirror] [PATCH 4.4] fscrypt: lock mutex before checking for bounce page pool

by Eric Biggers

commit a0b3bc855374c50b5ea85273553485af48caf2f7 upstream. [Please apply to 4.4-stable.] fscrypt_initialize(), which allocates the global bounce page pool when an encrypted file is first accessed, uses "double-checked locking" to try to avoid locking fscrypt_init_mutex. However, it doesn't use any memory barriers, so it's theoretically possible for a thread to observe a bounce page pool which has not been fully initialized. This is a classic bug with "double-checked locking". While "only a theoretical issue" in the latest kernel, in pre-4.8 kernels the pointer that was checked was not even the last to be initialized, so it was easily possible for a crash (NULL pointer dereference) to happen. This was changed only incidentally by the large refactor to use fs/crypto/. Solve both problems in a trivial way that can easily be backported: just always take the mutex. It's theoretically less efficient, but it shouldn't be noticeable in practice as the mutex is only acquired very briefly once per encrypted file. Later I'd like to make this use a helper macro like DO_ONCE(). However, DO_ONCE() runs in atomic context, so we'd need to add a new macro that allows blocking. Cc: stable(a)vger.kernel.org # v4.1+ Signed-off-by: Eric Biggers <ebiggers(a)google.com> Signed-off-by: Theodore Ts'o <tytso(a)mit.edu> --- fs/ext4/crypto_key.c | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/fs/ext4/crypto_key.c b/fs/ext4/crypto_key.c index 9a1bc638abce..9308fe4b66e6 100644 --- a/fs/ext4/crypto_key.c +++ b/fs/ext4/crypto_key.c @@ -129,11 +129,9 @@ int ext4_get_encryption_info(struct inode *inode) if (ei->i_crypt_info) return 0; - if (!ext4_read_workqueue) { - res = ext4_init_crypto(); - if (res) - return res; - } + res = ext4_init_crypto(); + if (res) + return res; res = ext4_xattr_get(inode, EXT4_XATTR_INDEX_ENCRYPTION, EXT4_XATTR_NAME_ENCRYPTION_CONTEXT, -- 2.15.0.417.g466bffb3ac-goog

7 years, 5 months

2
1
0 0

[Linux-stable-mirror] [PATCH 4.9] fscrypt: lock mutex before checking for bounce page pool

by Eric Biggers

commit a0b3bc855374c50b5ea85273553485af48caf2f7 upstream. [Please apply to 4.9-stable.] fscrypt_initialize(), which allocates the global bounce page pool when an encrypted file is first accessed, uses "double-checked locking" to try to avoid locking fscrypt_init_mutex. However, it doesn't use any memory barriers, so it's theoretically possible for a thread to observe a bounce page pool which has not been fully initialized. This is a classic bug with "double-checked locking". While "only a theoretical issue" in the latest kernel, in pre-4.8 kernels the pointer that was checked was not even the last to be initialized, so it was easily possible for a crash (NULL pointer dereference) to happen. This was changed only incidentally by the large refactor to use fs/crypto/. Solve both problems in a trivial way that can easily be backported: just always take the mutex. It's theoretically less efficient, but it shouldn't be noticeable in practice as the mutex is only acquired very briefly once per encrypted file. Later I'd like to make this use a helper macro like DO_ONCE(). However, DO_ONCE() runs in atomic context, so we'd need to add a new macro that allows blocking. Cc: stable(a)vger.kernel.org # v4.1+ Signed-off-by: Eric Biggers <ebiggers(a)google.com> Signed-off-by: Theodore Ts'o <tytso(a)mit.edu> --- fs/crypto/crypto.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/fs/crypto/crypto.c b/fs/crypto/crypto.c index 61cfccea77bc..73de1446c8d4 100644 --- a/fs/crypto/crypto.c +++ b/fs/crypto/crypto.c @@ -484,9 +484,6 @@ int fscrypt_initialize(void) { int i, res = -ENOMEM; - if (fscrypt_bounce_page_pool) - return 0; - mutex_lock(&fscrypt_init_mutex); if (fscrypt_bounce_page_pool) goto already_initialized; -- 2.15.0.417.g466bffb3ac-goog

7 years, 5 months

2
1
0 0

Re: [Linux-stable-mirror] [PATCH] Ensure that the SCSI error handler gets woken up

by Pavel Tikhomirov

1-st, Stuart - thanks for adding me to CC, 2-nd Bart - no idea why you didn't? =) > If scsi_eh_scmd_add() is called concurrently with scsi_host_queue_ready() > while shost->host_blocked > 0 then it can happen that neither function > wakes up the SCSI error handler. Fix this by making every function that > decreases the host_busy counter to wake up the error handler if necessary. Bart, you've added a comment to my initial patch() about performance, let me quote it here: > An important achievement of the scsi-mq code was removal of all > spin_lock_irq(shost->host_lock) statements from the hot path. The above > changes will have a significant negative performance impact, especially if > multiple LUNs associated with the same SCSI host are involved. Can the > reported race be fixed without slowing down the hot path significantly? I > think that both adding spin lock or smp_mb() calls in the hot path will > have a significant negative performance impact. These was a tricky question so I had no immediate answer. Here is the one: a) We need to check if scsi_eh_wakeup needs to wake up error handler thread in every place where we change host_busy. Else we have a chance that these change will break the wake up check in other existing places and will lead to deadlock. b) If we have several variables and change them (one different variable in in different thread) and after that we want to check the joint state of these variables, we sould surely have some kind of memory barriers to have a consistent state at some point. c) We already have spinlocks in scsi_schedule_eh, scsi_eh_scmd_add and scsi_device_unbusy, so it seems the good thing to reuse them for new checks too. I don't see another way to fix these problem. Your patch puts spinlocks under check which should itself be under spinlock, and breaks the initial fix (see Stuart's comment that the problem still reproduces). And you does _not_ answer your own question. > > Reported-by: Pavel Tikhomirov <ptikhomirov@xxxxxxxxxxxxx> > Fixes: commit 746650160866 ("scsi: convert host_busy to atomic_t") > Signed-off-by: Bart Van Assche <bart.vanassche@xxxxxxx> As your patch is based on my initial patch (https://patchwork.kernel.org/patch/9938919/), when all problems will be resolved with it, can you please add here: Signed-off-by: Pavel Tikhomirov <ptikhomirov(a)virtuozzo.com> > Cc: Konstantin Khorenko <khorenko@xxxxxxxxxxxxx> > Cc: Stuart Hayes <stuart.w.hayes@xxxxxxxxx> > Cc: Christoph Hellwig <hch@xxxxxx> > Cc: Hannes Reinecke <hare@xxxxxxxx> > Cc: Johannes Thumshirn <jthumshirn@xxxxxxx> > Cc: <stable@xxxxxxxxxxxxxxx> > --- > drivers/scsi/scsi_error.c | 3 ++- > drivers/scsi/scsi_lib.c | 22 ++++++++++++++-------- > 2 files changed, 16 insertions(+), 9 deletions(-) > > diff --git a/drivers/scsi/scsi_error.c b/drivers/scsi/scsi_error.c > index 5e89049e9b4e..f7f014c755d7 100644 > --- a/drivers/scsi/scsi_error.c > +++ b/drivers/scsi/scsi_error.c > @@ -61,9 +61,10 @@ static int scsi_eh_try_stu(struct scsi_cmnd *scmd); > static int scsi_try_to_abort_cmd(struct scsi_host_template *, > struct scsi_cmnd *); > > -/* called with shost->host_lock held */ > void scsi_eh_wakeup(struct Scsi_Host *shost) > { > + lockdep_assert_held(shost->host_lock); > + > if (atomic_read(&shost->host_busy) == shost->host_failed) { > trace_scsi_eh_wakeup(shost); > wake_up_process(shost->ehandler); I also think these hunk is just an additional precaution and should be in separate patch. > diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c > index 1e05e1885ac8..abd37d77af2d 100644 > --- a/drivers/scsi/scsi_lib.c > +++ b/drivers/scsi/scsi_lib.c > @@ -318,22 +318,28 @@ static void scsi_init_cmd_errh(struct scsi_cmnd *cmd) > cmd->cmd_len = scsi_command_size(cmd->cmnd); > } > > -void scsi_device_unbusy(struct scsi_device *sdev) > +static void scsi_dec_host_busy(struct Scsi_Host *shost) > { > - struct Scsi_Host *shost = sdev->host; > - struct scsi_target *starget = scsi_target(sdev); > unsigned long flags; > > atomic_dec(&shost->host_busy); > - if (starget->can_queue > 0) > - atomic_dec(&starget->target_busy); > - > if (unlikely(scsi_host_in_recovery(shost) && > (shost->host_failed || shost->host_eh_scheduled))) { As I've wrote above you do wrong locking here in scsi_dec_host_busy. Note that the above check reads host_failed and can load host_failed before host_busy is decremented due to reordering. > spin_lock_irqsave(shost->host_lock, flags); > scsi_eh_wakeup(shost); > spin_unlock_irqrestore(shost->host_lock, flags); > } > +} > + > +void scsi_device_unbusy(struct scsi_device *sdev) > +{ > + struct Scsi_Host *shost = sdev->host; > + struct scsi_target *starget = scsi_target(sdev); > + > + scsi_dec_host_busy(shost); > + > + if (starget->can_queue > 0) > + atomic_dec(&starget->target_busy); > > atomic_dec(&sdev->device_busy); > } > @@ -1532,7 +1538,7 @@ static inline int scsi_host_queue_ready(struct request_queue *q, > list_add_tail(&sdev->starved_entry, &shost->starved_list); > spin_unlock_irq(shost->host_lock); > out_dec: > - atomic_dec(&shost->host_busy); > + scsi_dec_host_busy(shost); > return 0; > } > > @@ -2020,7 +2026,7 @@ static blk_status_t scsi_queue_rq(struct blk_mq_hw_ctx *hctx, > return BLK_STS_OK; > > out_dec_host_busy: > - atomic_dec(&shost->host_busy); > + scsi_dec_host_busy(shost); > out_dec_target_busy: > if (scsi_target(sdev)->can_queue > 0) > atomic_dec(&scsi_target(sdev)->target_busy); > -- > 2.15.0 -- Best regards, Tikhomirov Pavel Software Developer, Virtuozzo.

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "sched/rt: Simplify the IPI based RT balancing logic" 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 sched/rt: Simplify the IPI based RT balancing logic 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: sched-rt-simplify-the-ipi-based-rt-balancing-logic.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 4bdced5c9a2922521e325896a7bbbf0132c94e56 Mon Sep 17 00:00:00 2001 From: "Steven Rostedt (Red Hat)" <rostedt(a)goodmis.org> Date: Fri, 6 Oct 2017 14:05:04 -0400 Subject: sched/rt: Simplify the IPI based RT balancing logic From: Steven Rostedt (Red Hat) <rostedt(a)goodmis.org> commit 4bdced5c9a2922521e325896a7bbbf0132c94e56 upstream. When a CPU lowers its priority (schedules out a high priority task for a lower priority one), a check is made to see if any other CPU has overloaded RT tasks (more than one). It checks the rto_mask to determine this and if so it will request to pull one of those tasks to itself if the non running RT task is of higher priority than the new priority of the next task to run on the current CPU. When we deal with large number of CPUs, the original pull logic suffered from large lock contention on a single CPU run queue, which caused a huge latency across all CPUs. This was caused by only having one CPU having overloaded RT tasks and a bunch of other CPUs lowering their priority. To solve this issue, commit: b6366f048e0c ("sched/rt: Use IPI to trigger RT task push migration instead of pulling") changed the way to request a pull. Instead of grabbing the lock of the overloaded CPU's runqueue, it simply sent an IPI to that CPU to do the work. Although the IPI logic worked very well in removing the large latency build up, it still could suffer from a large number of IPIs being sent to a single CPU. On a 80 CPU box, I measured over 200us of processing IPIs. Worse yet, when I tested this on a 120 CPU box, with a stress test that had lots of RT tasks scheduling on all CPUs, it actually triggered the hard lockup detector! One CPU had so many IPIs sent to it, and due to the restart mechanism that is triggered when the source run queue has a priority status change, the CPU spent minutes! processing the IPIs. Thinking about this further, I realized there's no reason for each run queue to send its own IPI. As all CPUs with overloaded tasks must be scanned regardless if there's one or many CPUs lowering their priority, because there's no current way to find the CPU with the highest priority task that can schedule to one of these CPUs, there really only needs to be one IPI being sent around at a time. This greatly simplifies the code! The new approach is to have each root domain have its own irq work, as the rto_mask is per root domain. The root domain has the following fields attached to it: rto_push_work - the irq work to process each CPU set in rto_mask rto_lock - the lock to protect some of the other rto fields rto_loop_start - an atomic that keeps contention down on rto_lock the first CPU scheduling in a lower priority task is the one to kick off the process. rto_loop_next - an atomic that gets incremented for each CPU that schedules in a lower priority task. rto_loop - a variable protected by rto_lock that is used to compare against rto_loop_next rto_cpu - The cpu to send the next IPI to, also protected by the rto_lock. When a CPU schedules in a lower priority task and wants to make sure overloaded CPUs know about it. It increments the rto_loop_next. Then it atomically sets rto_loop_start with a cmpxchg. If the old value is not "0", then it is done, as another CPU is kicking off the IPI loop. If the old value is "0", then it will take the rto_lock to synchronize with a possible IPI being sent around to the overloaded CPUs. If rto_cpu is greater than or equal to nr_cpu_ids, then there's either no IPI being sent around, or one is about to finish. Then rto_cpu is set to the first CPU in rto_mask and an IPI is sent to that CPU. If there's no CPUs set in rto_mask, then there's nothing to be done. When the CPU receives the IPI, it will first try to push any RT tasks that is queued on the CPU but can't run because a higher priority RT task is currently running on that CPU. Then it takes the rto_lock and looks for the next CPU in the rto_mask. If it finds one, it simply sends an IPI to that CPU and the process continues. If there's no more CPUs in the rto_mask, then rto_loop is compared with rto_loop_next. If they match, everything is done and the process is over. If they do not match, then a CPU scheduled in a lower priority task as the IPI was being passed around, and the process needs to start again. The first CPU in rto_mask is sent the IPI. This change removes this duplication of work in the IPI logic, and greatly lowers the latency caused by the IPIs. This removed the lockup happening on the 120 CPU machine. It also simplifies the code tremendously. What else could anyone ask for? Thanks to Peter Zijlstra for simplifying the rto_loop_start atomic logic and supplying me with the rto_start_trylock() and rto_start_unlock() helper functions. Signed-off-by: Steven Rostedt (VMware) <rostedt(a)goodmis.org> Signed-off-by: Peter Zijlstra (Intel) <peterz(a)infradead.org> Cc: Clark Williams <williams(a)redhat.com> Cc: Daniel Bristot de Oliveira <bristot(a)redhat.com> Cc: John Kacur <jkacur(a)redhat.com> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Mike Galbraith <efault(a)gmx.de> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Scott Wood <swood(a)redhat.com> Cc: Thomas Gleixner <tglx(a)linutronix.de> Link: http://lkml.kernel.org/r/20170424114732.1aac6dc4@gandalf.local.home Signed-off-by: Ingo Molnar <mingo(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- kernel/sched/core.c | 6 + kernel/sched/rt.c | 235 ++++++++++++++++++++++++--------------------------- kernel/sched/sched.h | 24 +++-- 3 files changed, 138 insertions(+), 127 deletions(-) --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -5877,6 +5877,12 @@ static int init_rootdomain(struct root_d if (!zalloc_cpumask_var(&rd->rto_mask, GFP_KERNEL)) goto free_dlo_mask; +#ifdef HAVE_RT_PUSH_IPI + rd->rto_cpu = -1; + raw_spin_lock_init(&rd->rto_lock); + init_irq_work(&rd->rto_push_work, rto_push_irq_work_func); +#endif + init_dl_bw(&rd->dl_bw); if (cpudl_init(&rd->cpudl) != 0) goto free_dlo_mask; --- a/kernel/sched/rt.c +++ b/kernel/sched/rt.c @@ -72,10 +72,6 @@ static void start_rt_bandwidth(struct rt raw_spin_unlock(&rt_b->rt_runtime_lock); } -#if defined(CONFIG_SMP) && defined(HAVE_RT_PUSH_IPI) -static void push_irq_work_func(struct irq_work *work); -#endif - void init_rt_rq(struct rt_rq *rt_rq) { struct rt_prio_array *array; @@ -95,13 +91,6 @@ void init_rt_rq(struct rt_rq *rt_rq) rt_rq->rt_nr_migratory = 0; rt_rq->overloaded = 0; plist_head_init(&rt_rq->pushable_tasks); - -#ifdef HAVE_RT_PUSH_IPI - rt_rq->push_flags = 0; - rt_rq->push_cpu = nr_cpu_ids; - raw_spin_lock_init(&rt_rq->push_lock); - init_irq_work(&rt_rq->push_work, push_irq_work_func); -#endif #endif /* CONFIG_SMP */ /* We start is dequeued state, because no RT tasks are queued */ rt_rq->rt_queued = 0; @@ -1864,160 +1853,166 @@ static void push_rt_tasks(struct rq *rq) } #ifdef HAVE_RT_PUSH_IPI + /* - * The search for the next cpu always starts at rq->cpu and ends - * when we reach rq->cpu again. It will never return rq->cpu. - * This returns the next cpu to check, or nr_cpu_ids if the loop - * is complete. + * When a high priority task schedules out from a CPU and a lower priority + * task is scheduled in, a check is made to see if there's any RT tasks + * on other CPUs that are waiting to run because a higher priority RT task + * is currently running on its CPU. In this case, the CPU with multiple RT + * tasks queued on it (overloaded) needs to be notified that a CPU has opened + * up that may be able to run one of its non-running queued RT tasks. + * + * All CPUs with overloaded RT tasks need to be notified as there is currently + * no way to know which of these CPUs have the highest priority task waiting + * to run. Instead of trying to take a spinlock on each of these CPUs, + * which has shown to cause large latency when done on machines with many + * CPUs, sending an IPI to the CPUs to have them push off the overloaded + * RT tasks waiting to run. + * + * Just sending an IPI to each of the CPUs is also an issue, as on large + * count CPU machines, this can cause an IPI storm on a CPU, especially + * if its the only CPU with multiple RT tasks queued, and a large number + * of CPUs scheduling a lower priority task at the same time. + * + * Each root domain has its own irq work function that can iterate over + * all CPUs with RT overloaded tasks. Since all CPUs with overloaded RT + * tassk must be checked if there's one or many CPUs that are lowering + * their priority, there's a single irq work iterator that will try to + * push off RT tasks that are waiting to run. + * + * When a CPU schedules a lower priority task, it will kick off the + * irq work iterator that will jump to each CPU with overloaded RT tasks. + * As it only takes the first CPU that schedules a lower priority task + * to start the process, the rto_start variable is incremented and if + * the atomic result is one, then that CPU will try to take the rto_lock. + * This prevents high contention on the lock as the process handles all + * CPUs scheduling lower priority tasks. + * + * All CPUs that are scheduling a lower priority task will increment the + * rt_loop_next variable. This will make sure that the irq work iterator + * checks all RT overloaded CPUs whenever a CPU schedules a new lower + * priority task, even if the iterator is in the middle of a scan. Incrementing + * the rt_loop_next will cause the iterator to perform another scan. * - * rq->rt.push_cpu holds the last cpu returned by this function, - * or if this is the first instance, it must hold rq->cpu. */ static int rto_next_cpu(struct rq *rq) { - int prev_cpu = rq->rt.push_cpu; + struct root_domain *rd = rq->rd; + int next; int cpu; - cpu = cpumask_next(prev_cpu, rq->rd->rto_mask); - /* - * If the previous cpu is less than the rq's CPU, then it already - * passed the end of the mask, and has started from the beginning. - * We end if the next CPU is greater or equal to rq's CPU. + * When starting the IPI RT pushing, the rto_cpu is set to -1, + * rt_next_cpu() will simply return the first CPU found in + * the rto_mask. + * + * If rto_next_cpu() is called with rto_cpu is a valid cpu, it + * will return the next CPU found in the rto_mask. + * + * If there are no more CPUs left in the rto_mask, then a check is made + * against rto_loop and rto_loop_next. rto_loop is only updated with + * the rto_lock held, but any CPU may increment the rto_loop_next + * without any locking. */ - if (prev_cpu < rq->cpu) { - if (cpu >= rq->cpu) - return nr_cpu_ids; + for (;;) { - } else if (cpu >= nr_cpu_ids) { - /* - * We passed the end of the mask, start at the beginning. - * If the result is greater or equal to the rq's CPU, then - * the loop is finished. - */ - cpu = cpumask_first(rq->rd->rto_mask); - if (cpu >= rq->cpu) - return nr_cpu_ids; - } - rq->rt.push_cpu = cpu; + /* When rto_cpu is -1 this acts like cpumask_first() */ + cpu = cpumask_next(rd->rto_cpu, rd->rto_mask); - /* Return cpu to let the caller know if the loop is finished or not */ - return cpu; -} + rd->rto_cpu = cpu; -static int find_next_push_cpu(struct rq *rq) -{ - struct rq *next_rq; - int cpu; + if (cpu < nr_cpu_ids) + return cpu; - while (1) { - cpu = rto_next_cpu(rq); - if (cpu >= nr_cpu_ids) - break; - next_rq = cpu_rq(cpu); + rd->rto_cpu = -1; + + /* + * ACQUIRE ensures we see the @rto_mask changes + * made prior to the @next value observed. + * + * Matches WMB in rt_set_overload(). + */ + next = atomic_read_acquire(&rd->rto_loop_next); - /* Make sure the next rq can push to this rq */ - if (next_rq->rt.highest_prio.next < rq->rt.highest_prio.curr) + if (rd->rto_loop == next) break; + + rd->rto_loop = next; } - return cpu; + return -1; } -#define RT_PUSH_IPI_EXECUTING 1 -#define RT_PUSH_IPI_RESTART 2 +static inline bool rto_start_trylock(atomic_t *v) +{ + return !atomic_cmpxchg_acquire(v, 0, 1); +} -static void tell_cpu_to_push(struct rq *rq) +static inline void rto_start_unlock(atomic_t *v) { - int cpu; + atomic_set_release(v, 0); +} - if (rq->rt.push_flags & RT_PUSH_IPI_EXECUTING) { - raw_spin_lock(&rq->rt.push_lock); - /* Make sure it's still executing */ - if (rq->rt.push_flags & RT_PUSH_IPI_EXECUTING) { - /* - * Tell the IPI to restart the loop as things have - * changed since it started. - */ - rq->rt.push_flags |= RT_PUSH_IPI_RESTART; - raw_spin_unlock(&rq->rt.push_lock); - return; - } - raw_spin_unlock(&rq->rt.push_lock); - } +static void tell_cpu_to_push(struct rq *rq) +{ + int cpu = -1; - /* When here, there's no IPI going around */ + /* Keep the loop going if the IPI is currently active */ + atomic_inc(&rq->rd->rto_loop_next); - rq->rt.push_cpu = rq->cpu; - cpu = find_next_push_cpu(rq); - if (cpu >= nr_cpu_ids) + /* Only one CPU can initiate a loop at a time */ + if (!rto_start_trylock(&rq->rd->rto_loop_start)) return; - rq->rt.push_flags = RT_PUSH_IPI_EXECUTING; + raw_spin_lock(&rq->rd->rto_lock); + + /* + * The rto_cpu is updated under the lock, if it has a valid cpu + * then the IPI is still running and will continue due to the + * update to loop_next, and nothing needs to be done here. + * Otherwise it is finishing up and an ipi needs to be sent. + */ + if (rq->rd->rto_cpu < 0) + cpu = rto_next_cpu(rq); + + raw_spin_unlock(&rq->rd->rto_lock); - irq_work_queue_on(&rq->rt.push_work, cpu); + rto_start_unlock(&rq->rd->rto_loop_start); + + if (cpu >= 0) + irq_work_queue_on(&rq->rd->rto_push_work, cpu); } /* Called from hardirq context */ -static void try_to_push_tasks(void *arg) +void rto_push_irq_work_func(struct irq_work *work) { - struct rt_rq *rt_rq = arg; - struct rq *rq, *src_rq; - int this_cpu; + struct rq *rq; int cpu; - this_cpu = rt_rq->push_cpu; + rq = this_rq(); - /* Paranoid check */ - BUG_ON(this_cpu != smp_processor_id()); - - rq = cpu_rq(this_cpu); - src_rq = rq_of_rt_rq(rt_rq); - -again: + /* + * We do not need to grab the lock to check for has_pushable_tasks. + * When it gets updated, a check is made if a push is possible. + */ if (has_pushable_tasks(rq)) { raw_spin_lock(&rq->lock); - push_rt_task(rq); + push_rt_tasks(rq); raw_spin_unlock(&rq->lock); } - /* Pass the IPI to the next rt overloaded queue */ - raw_spin_lock(&rt_rq->push_lock); - /* - * If the source queue changed since the IPI went out, - * we need to restart the search from that CPU again. - */ - if (rt_rq->push_flags & RT_PUSH_IPI_RESTART) { - rt_rq->push_flags &= ~RT_PUSH_IPI_RESTART; - rt_rq->push_cpu = src_rq->cpu; - } + raw_spin_lock(&rq->rd->rto_lock); - cpu = find_next_push_cpu(src_rq); + /* Pass the IPI to the next rt overloaded queue */ + cpu = rto_next_cpu(rq); - if (cpu >= nr_cpu_ids) - rt_rq->push_flags &= ~RT_PUSH_IPI_EXECUTING; - raw_spin_unlock(&rt_rq->push_lock); + raw_spin_unlock(&rq->rd->rto_lock); - if (cpu >= nr_cpu_ids) + if (cpu < 0) return; - /* - * It is possible that a restart caused this CPU to be - * chosen again. Don't bother with an IPI, just see if we - * have more to push. - */ - if (unlikely(cpu == rq->cpu)) - goto again; - /* Try the next RT overloaded CPU */ - irq_work_queue_on(&rt_rq->push_work, cpu); -} - -static void push_irq_work_func(struct irq_work *work) -{ - struct rt_rq *rt_rq = container_of(work, struct rt_rq, push_work); - - try_to_push_tasks(rt_rq); + irq_work_queue_on(&rq->rd->rto_push_work, cpu); } #endif /* HAVE_RT_PUSH_IPI */ --- a/kernel/sched/sched.h +++ b/kernel/sched/sched.h @@ -463,7 +463,7 @@ static inline int rt_bandwidth_enabled(v } /* RT IPI pull logic requires IRQ_WORK */ -#ifdef CONFIG_IRQ_WORK +#if defined(CONFIG_IRQ_WORK) && defined(CONFIG_SMP) # define HAVE_RT_PUSH_IPI #endif @@ -485,12 +485,6 @@ struct rt_rq { unsigned long rt_nr_total; int overloaded; struct plist_head pushable_tasks; -#ifdef HAVE_RT_PUSH_IPI - int push_flags; - int push_cpu; - struct irq_work push_work; - raw_spinlock_t push_lock; -#endif #endif /* CONFIG_SMP */ int rt_queued; @@ -572,6 +566,19 @@ struct root_domain { struct dl_bw dl_bw; struct cpudl cpudl; +#ifdef HAVE_RT_PUSH_IPI + /* + * For IPI pull requests, loop across the rto_mask. + */ + struct irq_work rto_push_work; + raw_spinlock_t rto_lock; + /* These are only updated and read within rto_lock */ + int rto_loop; + int rto_cpu; + /* These atomics are updated outside of a lock */ + atomic_t rto_loop_next; + atomic_t rto_loop_start; +#endif /* * The "RT overload" flag: it gets set if a CPU has more than * one runnable RT task. @@ -584,6 +591,9 @@ struct root_domain { extern struct root_domain def_root_domain; +#ifdef HAVE_RT_PUSH_IPI +extern void rto_push_irq_work_func(struct irq_work *work); +#endif #endif /* CONFIG_SMP */ /* Patches currently in stable-queue which might be from rostedt(a)goodmis.org are queue-4.9/sched-make-resched_cpu-unconditional.patch queue-4.9/sched-rt-simplify-the-ipi-based-rt-balancing-logic.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "sched/rt: Simplify the IPI based RT balancing logic" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled sched/rt: Simplify the IPI based RT balancing logic to the 4.4-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: sched-rt-simplify-the-ipi-based-rt-balancing-logic.patch and it can be found in the queue-4.4 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 4bdced5c9a2922521e325896a7bbbf0132c94e56 Mon Sep 17 00:00:00 2001 From: "Steven Rostedt (Red Hat)" <rostedt(a)goodmis.org> Date: Fri, 6 Oct 2017 14:05:04 -0400 Subject: sched/rt: Simplify the IPI based RT balancing logic From: Steven Rostedt (Red Hat) <rostedt(a)goodmis.org> commit 4bdced5c9a2922521e325896a7bbbf0132c94e56 upstream. When a CPU lowers its priority (schedules out a high priority task for a lower priority one), a check is made to see if any other CPU has overloaded RT tasks (more than one). It checks the rto_mask to determine this and if so it will request to pull one of those tasks to itself if the non running RT task is of higher priority than the new priority of the next task to run on the current CPU. When we deal with large number of CPUs, the original pull logic suffered from large lock contention on a single CPU run queue, which caused a huge latency across all CPUs. This was caused by only having one CPU having overloaded RT tasks and a bunch of other CPUs lowering their priority. To solve this issue, commit: b6366f048e0c ("sched/rt: Use IPI to trigger RT task push migration instead of pulling") changed the way to request a pull. Instead of grabbing the lock of the overloaded CPU's runqueue, it simply sent an IPI to that CPU to do the work. Although the IPI logic worked very well in removing the large latency build up, it still could suffer from a large number of IPIs being sent to a single CPU. On a 80 CPU box, I measured over 200us of processing IPIs. Worse yet, when I tested this on a 120 CPU box, with a stress test that had lots of RT tasks scheduling on all CPUs, it actually triggered the hard lockup detector! One CPU had so many IPIs sent to it, and due to the restart mechanism that is triggered when the source run queue has a priority status change, the CPU spent minutes! processing the IPIs. Thinking about this further, I realized there's no reason for each run queue to send its own IPI. As all CPUs with overloaded tasks must be scanned regardless if there's one or many CPUs lowering their priority, because there's no current way to find the CPU with the highest priority task that can schedule to one of these CPUs, there really only needs to be one IPI being sent around at a time. This greatly simplifies the code! The new approach is to have each root domain have its own irq work, as the rto_mask is per root domain. The root domain has the following fields attached to it: rto_push_work - the irq work to process each CPU set in rto_mask rto_lock - the lock to protect some of the other rto fields rto_loop_start - an atomic that keeps contention down on rto_lock the first CPU scheduling in a lower priority task is the one to kick off the process. rto_loop_next - an atomic that gets incremented for each CPU that schedules in a lower priority task. rto_loop - a variable protected by rto_lock that is used to compare against rto_loop_next rto_cpu - The cpu to send the next IPI to, also protected by the rto_lock. When a CPU schedules in a lower priority task and wants to make sure overloaded CPUs know about it. It increments the rto_loop_next. Then it atomically sets rto_loop_start with a cmpxchg. If the old value is not "0", then it is done, as another CPU is kicking off the IPI loop. If the old value is "0", then it will take the rto_lock to synchronize with a possible IPI being sent around to the overloaded CPUs. If rto_cpu is greater than or equal to nr_cpu_ids, then there's either no IPI being sent around, or one is about to finish. Then rto_cpu is set to the first CPU in rto_mask and an IPI is sent to that CPU. If there's no CPUs set in rto_mask, then there's nothing to be done. When the CPU receives the IPI, it will first try to push any RT tasks that is queued on the CPU but can't run because a higher priority RT task is currently running on that CPU. Then it takes the rto_lock and looks for the next CPU in the rto_mask. If it finds one, it simply sends an IPI to that CPU and the process continues. If there's no more CPUs in the rto_mask, then rto_loop is compared with rto_loop_next. If they match, everything is done and the process is over. If they do not match, then a CPU scheduled in a lower priority task as the IPI was being passed around, and the process needs to start again. The first CPU in rto_mask is sent the IPI. This change removes this duplication of work in the IPI logic, and greatly lowers the latency caused by the IPIs. This removed the lockup happening on the 120 CPU machine. It also simplifies the code tremendously. What else could anyone ask for? Thanks to Peter Zijlstra for simplifying the rto_loop_start atomic logic and supplying me with the rto_start_trylock() and rto_start_unlock() helper functions. Signed-off-by: Steven Rostedt (VMware) <rostedt(a)goodmis.org> Signed-off-by: Peter Zijlstra (Intel) <peterz(a)infradead.org> Cc: Clark Williams <williams(a)redhat.com> Cc: Daniel Bristot de Oliveira <bristot(a)redhat.com> Cc: John Kacur <jkacur(a)redhat.com> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Mike Galbraith <efault(a)gmx.de> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Scott Wood <swood(a)redhat.com> Cc: Thomas Gleixner <tglx(a)linutronix.de> Link: http://lkml.kernel.org/r/20170424114732.1aac6dc4@gandalf.local.home Signed-off-by: Ingo Molnar <mingo(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- kernel/sched/core.c | 6 + kernel/sched/rt.c | 235 ++++++++++++++++++++++++--------------------------- kernel/sched/sched.h | 24 +++-- 3 files changed, 138 insertions(+), 127 deletions(-) --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -5907,6 +5907,12 @@ static int init_rootdomain(struct root_d if (!zalloc_cpumask_var(&rd->rto_mask, GFP_KERNEL)) goto free_dlo_mask; +#ifdef HAVE_RT_PUSH_IPI + rd->rto_cpu = -1; + raw_spin_lock_init(&rd->rto_lock); + init_irq_work(&rd->rto_push_work, rto_push_irq_work_func); +#endif + init_dl_bw(&rd->dl_bw); if (cpudl_init(&rd->cpudl) != 0) goto free_dlo_mask; --- a/kernel/sched/rt.c +++ b/kernel/sched/rt.c @@ -64,10 +64,6 @@ static void start_rt_bandwidth(struct rt raw_spin_unlock(&rt_b->rt_runtime_lock); } -#if defined(CONFIG_SMP) && defined(HAVE_RT_PUSH_IPI) -static void push_irq_work_func(struct irq_work *work); -#endif - void init_rt_rq(struct rt_rq *rt_rq) { struct rt_prio_array *array; @@ -87,13 +83,6 @@ void init_rt_rq(struct rt_rq *rt_rq) rt_rq->rt_nr_migratory = 0; rt_rq->overloaded = 0; plist_head_init(&rt_rq->pushable_tasks); - -#ifdef HAVE_RT_PUSH_IPI - rt_rq->push_flags = 0; - rt_rq->push_cpu = nr_cpu_ids; - raw_spin_lock_init(&rt_rq->push_lock); - init_irq_work(&rt_rq->push_work, push_irq_work_func); -#endif #endif /* CONFIG_SMP */ /* We start is dequeued state, because no RT tasks are queued */ rt_rq->rt_queued = 0; @@ -1802,160 +1791,166 @@ static void push_rt_tasks(struct rq *rq) } #ifdef HAVE_RT_PUSH_IPI + /* - * The search for the next cpu always starts at rq->cpu and ends - * when we reach rq->cpu again. It will never return rq->cpu. - * This returns the next cpu to check, or nr_cpu_ids if the loop - * is complete. + * When a high priority task schedules out from a CPU and a lower priority + * task is scheduled in, a check is made to see if there's any RT tasks + * on other CPUs that are waiting to run because a higher priority RT task + * is currently running on its CPU. In this case, the CPU with multiple RT + * tasks queued on it (overloaded) needs to be notified that a CPU has opened + * up that may be able to run one of its non-running queued RT tasks. + * + * All CPUs with overloaded RT tasks need to be notified as there is currently + * no way to know which of these CPUs have the highest priority task waiting + * to run. Instead of trying to take a spinlock on each of these CPUs, + * which has shown to cause large latency when done on machines with many + * CPUs, sending an IPI to the CPUs to have them push off the overloaded + * RT tasks waiting to run. + * + * Just sending an IPI to each of the CPUs is also an issue, as on large + * count CPU machines, this can cause an IPI storm on a CPU, especially + * if its the only CPU with multiple RT tasks queued, and a large number + * of CPUs scheduling a lower priority task at the same time. + * + * Each root domain has its own irq work function that can iterate over + * all CPUs with RT overloaded tasks. Since all CPUs with overloaded RT + * tassk must be checked if there's one or many CPUs that are lowering + * their priority, there's a single irq work iterator that will try to + * push off RT tasks that are waiting to run. + * + * When a CPU schedules a lower priority task, it will kick off the + * irq work iterator that will jump to each CPU with overloaded RT tasks. + * As it only takes the first CPU that schedules a lower priority task + * to start the process, the rto_start variable is incremented and if + * the atomic result is one, then that CPU will try to take the rto_lock. + * This prevents high contention on the lock as the process handles all + * CPUs scheduling lower priority tasks. + * + * All CPUs that are scheduling a lower priority task will increment the + * rt_loop_next variable. This will make sure that the irq work iterator + * checks all RT overloaded CPUs whenever a CPU schedules a new lower + * priority task, even if the iterator is in the middle of a scan. Incrementing + * the rt_loop_next will cause the iterator to perform another scan. * - * rq->rt.push_cpu holds the last cpu returned by this function, - * or if this is the first instance, it must hold rq->cpu. */ static int rto_next_cpu(struct rq *rq) { - int prev_cpu = rq->rt.push_cpu; + struct root_domain *rd = rq->rd; + int next; int cpu; - cpu = cpumask_next(prev_cpu, rq->rd->rto_mask); - /* - * If the previous cpu is less than the rq's CPU, then it already - * passed the end of the mask, and has started from the beginning. - * We end if the next CPU is greater or equal to rq's CPU. + * When starting the IPI RT pushing, the rto_cpu is set to -1, + * rt_next_cpu() will simply return the first CPU found in + * the rto_mask. + * + * If rto_next_cpu() is called with rto_cpu is a valid cpu, it + * will return the next CPU found in the rto_mask. + * + * If there are no more CPUs left in the rto_mask, then a check is made + * against rto_loop and rto_loop_next. rto_loop is only updated with + * the rto_lock held, but any CPU may increment the rto_loop_next + * without any locking. */ - if (prev_cpu < rq->cpu) { - if (cpu >= rq->cpu) - return nr_cpu_ids; + for (;;) { - } else if (cpu >= nr_cpu_ids) { - /* - * We passed the end of the mask, start at the beginning. - * If the result is greater or equal to the rq's CPU, then - * the loop is finished. - */ - cpu = cpumask_first(rq->rd->rto_mask); - if (cpu >= rq->cpu) - return nr_cpu_ids; - } - rq->rt.push_cpu = cpu; + /* When rto_cpu is -1 this acts like cpumask_first() */ + cpu = cpumask_next(rd->rto_cpu, rd->rto_mask); - /* Return cpu to let the caller know if the loop is finished or not */ - return cpu; -} + rd->rto_cpu = cpu; -static int find_next_push_cpu(struct rq *rq) -{ - struct rq *next_rq; - int cpu; + if (cpu < nr_cpu_ids) + return cpu; - while (1) { - cpu = rto_next_cpu(rq); - if (cpu >= nr_cpu_ids) - break; - next_rq = cpu_rq(cpu); + rd->rto_cpu = -1; + + /* + * ACQUIRE ensures we see the @rto_mask changes + * made prior to the @next value observed. + * + * Matches WMB in rt_set_overload(). + */ + next = atomic_read_acquire(&rd->rto_loop_next); - /* Make sure the next rq can push to this rq */ - if (next_rq->rt.highest_prio.next < rq->rt.highest_prio.curr) + if (rd->rto_loop == next) break; + + rd->rto_loop = next; } - return cpu; + return -1; } -#define RT_PUSH_IPI_EXECUTING 1 -#define RT_PUSH_IPI_RESTART 2 +static inline bool rto_start_trylock(atomic_t *v) +{ + return !atomic_cmpxchg_acquire(v, 0, 1); +} -static void tell_cpu_to_push(struct rq *rq) +static inline void rto_start_unlock(atomic_t *v) { - int cpu; + atomic_set_release(v, 0); +} - if (rq->rt.push_flags & RT_PUSH_IPI_EXECUTING) { - raw_spin_lock(&rq->rt.push_lock); - /* Make sure it's still executing */ - if (rq->rt.push_flags & RT_PUSH_IPI_EXECUTING) { - /* - * Tell the IPI to restart the loop as things have - * changed since it started. - */ - rq->rt.push_flags |= RT_PUSH_IPI_RESTART; - raw_spin_unlock(&rq->rt.push_lock); - return; - } - raw_spin_unlock(&rq->rt.push_lock); - } +static void tell_cpu_to_push(struct rq *rq) +{ + int cpu = -1; - /* When here, there's no IPI going around */ + /* Keep the loop going if the IPI is currently active */ + atomic_inc(&rq->rd->rto_loop_next); - rq->rt.push_cpu = rq->cpu; - cpu = find_next_push_cpu(rq); - if (cpu >= nr_cpu_ids) + /* Only one CPU can initiate a loop at a time */ + if (!rto_start_trylock(&rq->rd->rto_loop_start)) return; - rq->rt.push_flags = RT_PUSH_IPI_EXECUTING; + raw_spin_lock(&rq->rd->rto_lock); + + /* + * The rto_cpu is updated under the lock, if it has a valid cpu + * then the IPI is still running and will continue due to the + * update to loop_next, and nothing needs to be done here. + * Otherwise it is finishing up and an ipi needs to be sent. + */ + if (rq->rd->rto_cpu < 0) + cpu = rto_next_cpu(rq); + + raw_spin_unlock(&rq->rd->rto_lock); - irq_work_queue_on(&rq->rt.push_work, cpu); + rto_start_unlock(&rq->rd->rto_loop_start); + + if (cpu >= 0) + irq_work_queue_on(&rq->rd->rto_push_work, cpu); } /* Called from hardirq context */ -static void try_to_push_tasks(void *arg) +void rto_push_irq_work_func(struct irq_work *work) { - struct rt_rq *rt_rq = arg; - struct rq *rq, *src_rq; - int this_cpu; + struct rq *rq; int cpu; - this_cpu = rt_rq->push_cpu; + rq = this_rq(); - /* Paranoid check */ - BUG_ON(this_cpu != smp_processor_id()); - - rq = cpu_rq(this_cpu); - src_rq = rq_of_rt_rq(rt_rq); - -again: + /* + * We do not need to grab the lock to check for has_pushable_tasks. + * When it gets updated, a check is made if a push is possible. + */ if (has_pushable_tasks(rq)) { raw_spin_lock(&rq->lock); - push_rt_task(rq); + push_rt_tasks(rq); raw_spin_unlock(&rq->lock); } - /* Pass the IPI to the next rt overloaded queue */ - raw_spin_lock(&rt_rq->push_lock); - /* - * If the source queue changed since the IPI went out, - * we need to restart the search from that CPU again. - */ - if (rt_rq->push_flags & RT_PUSH_IPI_RESTART) { - rt_rq->push_flags &= ~RT_PUSH_IPI_RESTART; - rt_rq->push_cpu = src_rq->cpu; - } + raw_spin_lock(&rq->rd->rto_lock); - cpu = find_next_push_cpu(src_rq); + /* Pass the IPI to the next rt overloaded queue */ + cpu = rto_next_cpu(rq); - if (cpu >= nr_cpu_ids) - rt_rq->push_flags &= ~RT_PUSH_IPI_EXECUTING; - raw_spin_unlock(&rt_rq->push_lock); + raw_spin_unlock(&rq->rd->rto_lock); - if (cpu >= nr_cpu_ids) + if (cpu < 0) return; - /* - * It is possible that a restart caused this CPU to be - * chosen again. Don't bother with an IPI, just see if we - * have more to push. - */ - if (unlikely(cpu == rq->cpu)) - goto again; - /* Try the next RT overloaded CPU */ - irq_work_queue_on(&rt_rq->push_work, cpu); -} - -static void push_irq_work_func(struct irq_work *work) -{ - struct rt_rq *rt_rq = container_of(work, struct rt_rq, push_work); - - try_to_push_tasks(rt_rq); + irq_work_queue_on(&rq->rd->rto_push_work, cpu); } #endif /* HAVE_RT_PUSH_IPI */ --- a/kernel/sched/sched.h +++ b/kernel/sched/sched.h @@ -429,7 +429,7 @@ static inline int rt_bandwidth_enabled(v } /* RT IPI pull logic requires IRQ_WORK */ -#ifdef CONFIG_IRQ_WORK +#if defined(CONFIG_IRQ_WORK) && defined(CONFIG_SMP) # define HAVE_RT_PUSH_IPI #endif @@ -450,12 +450,6 @@ struct rt_rq { unsigned long rt_nr_total; int overloaded; struct plist_head pushable_tasks; -#ifdef HAVE_RT_PUSH_IPI - int push_flags; - int push_cpu; - struct irq_work push_work; - raw_spinlock_t push_lock; -#endif #endif /* CONFIG_SMP */ int rt_queued; @@ -537,6 +531,19 @@ struct root_domain { struct dl_bw dl_bw; struct cpudl cpudl; +#ifdef HAVE_RT_PUSH_IPI + /* + * For IPI pull requests, loop across the rto_mask. + */ + struct irq_work rto_push_work; + raw_spinlock_t rto_lock; + /* These are only updated and read within rto_lock */ + int rto_loop; + int rto_cpu; + /* These atomics are updated outside of a lock */ + atomic_t rto_loop_next; + atomic_t rto_loop_start; +#endif /* * The "RT overload" flag: it gets set if a CPU has more than * one runnable RT task. @@ -547,6 +554,9 @@ struct root_domain { extern struct root_domain def_root_domain; +#ifdef HAVE_RT_PUSH_IPI +extern void rto_push_irq_work_func(struct irq_work *work); +#endif #endif /* CONFIG_SMP */ /* Patches currently in stable-queue which might be from rostedt(a)goodmis.org are queue-4.4/sched-make-resched_cpu-unconditional.patch queue-4.4/sched-rt-simplify-the-ipi-based-rt-balancing-logic.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] FAILED: patch "[PATCH] sched/rt: Simplify the IPI based RT balancing logic" failed to apply to 4.9-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.9-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 4bdced5c9a2922521e325896a7bbbf0132c94e56 Mon Sep 17 00:00:00 2001 From: "Steven Rostedt (Red Hat)" <rostedt(a)goodmis.org> Date: Fri, 6 Oct 2017 14:05:04 -0400 Subject: [PATCH] sched/rt: Simplify the IPI based RT balancing logic When a CPU lowers its priority (schedules out a high priority task for a lower priority one), a check is made to see if any other CPU has overloaded RT tasks (more than one). It checks the rto_mask to determine this and if so it will request to pull one of those tasks to itself if the non running RT task is of higher priority than the new priority of the next task to run on the current CPU. When we deal with large number of CPUs, the original pull logic suffered from large lock contention on a single CPU run queue, which caused a huge latency across all CPUs. This was caused by only having one CPU having overloaded RT tasks and a bunch of other CPUs lowering their priority. To solve this issue, commit: b6366f048e0c ("sched/rt: Use IPI to trigger RT task push migration instead of pulling") changed the way to request a pull. Instead of grabbing the lock of the overloaded CPU's runqueue, it simply sent an IPI to that CPU to do the work. Although the IPI logic worked very well in removing the large latency build up, it still could suffer from a large number of IPIs being sent to a single CPU. On a 80 CPU box, I measured over 200us of processing IPIs. Worse yet, when I tested this on a 120 CPU box, with a stress test that had lots of RT tasks scheduling on all CPUs, it actually triggered the hard lockup detector! One CPU had so many IPIs sent to it, and due to the restart mechanism that is triggered when the source run queue has a priority status change, the CPU spent minutes! processing the IPIs. Thinking about this further, I realized there's no reason for each run queue to send its own IPI. As all CPUs with overloaded tasks must be scanned regardless if there's one or many CPUs lowering their priority, because there's no current way to find the CPU with the highest priority task that can schedule to one of these CPUs, there really only needs to be one IPI being sent around at a time. This greatly simplifies the code! The new approach is to have each root domain have its own irq work, as the rto_mask is per root domain. The root domain has the following fields attached to it: rto_push_work - the irq work to process each CPU set in rto_mask rto_lock - the lock to protect some of the other rto fields rto_loop_start - an atomic that keeps contention down on rto_lock the first CPU scheduling in a lower priority task is the one to kick off the process. rto_loop_next - an atomic that gets incremented for each CPU that schedules in a lower priority task. rto_loop - a variable protected by rto_lock that is used to compare against rto_loop_next rto_cpu - The cpu to send the next IPI to, also protected by the rto_lock. When a CPU schedules in a lower priority task and wants to make sure overloaded CPUs know about it. It increments the rto_loop_next. Then it atomically sets rto_loop_start with a cmpxchg. If the old value is not "0", then it is done, as another CPU is kicking off the IPI loop. If the old value is "0", then it will take the rto_lock to synchronize with a possible IPI being sent around to the overloaded CPUs. If rto_cpu is greater than or equal to nr_cpu_ids, then there's either no IPI being sent around, or one is about to finish. Then rto_cpu is set to the first CPU in rto_mask and an IPI is sent to that CPU. If there's no CPUs set in rto_mask, then there's nothing to be done. When the CPU receives the IPI, it will first try to push any RT tasks that is queued on the CPU but can't run because a higher priority RT task is currently running on that CPU. Then it takes the rto_lock and looks for the next CPU in the rto_mask. If it finds one, it simply sends an IPI to that CPU and the process continues. If there's no more CPUs in the rto_mask, then rto_loop is compared with rto_loop_next. If they match, everything is done and the process is over. If they do not match, then a CPU scheduled in a lower priority task as the IPI was being passed around, and the process needs to start again. The first CPU in rto_mask is sent the IPI. This change removes this duplication of work in the IPI logic, and greatly lowers the latency caused by the IPIs. This removed the lockup happening on the 120 CPU machine. It also simplifies the code tremendously. What else could anyone ask for? Thanks to Peter Zijlstra for simplifying the rto_loop_start atomic logic and supplying me with the rto_start_trylock() and rto_start_unlock() helper functions. Signed-off-by: Steven Rostedt (VMware) <rostedt(a)goodmis.org> Signed-off-by: Peter Zijlstra (Intel) <peterz(a)infradead.org> Cc: Clark Williams <williams(a)redhat.com> Cc: Daniel Bristot de Oliveira <bristot(a)redhat.com> Cc: John Kacur <jkacur(a)redhat.com> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Mike Galbraith <efault(a)gmx.de> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Scott Wood <swood(a)redhat.com> Cc: Thomas Gleixner <tglx(a)linutronix.de> Link: http://lkml.kernel.org/r/20170424114732.1aac6dc4@gandalf.local.home Signed-off-by: Ingo Molnar <mingo(a)kernel.org> diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c index 0af5ca9e3e3f..fda27991699a 100644 --- a/kernel/sched/rt.c +++ b/kernel/sched/rt.c @@ -73,10 +73,6 @@ static void start_rt_bandwidth(struct rt_bandwidth *rt_b) raw_spin_unlock(&rt_b->rt_runtime_lock); } -#if defined(CONFIG_SMP) && defined(HAVE_RT_PUSH_IPI) -static void push_irq_work_func(struct irq_work *work); -#endif - void init_rt_rq(struct rt_rq *rt_rq) { struct rt_prio_array *array; @@ -96,13 +92,6 @@ void init_rt_rq(struct rt_rq *rt_rq) rt_rq->rt_nr_migratory = 0; rt_rq->overloaded = 0; plist_head_init(&rt_rq->pushable_tasks); - -#ifdef HAVE_RT_PUSH_IPI - rt_rq->push_flags = 0; - rt_rq->push_cpu = nr_cpu_ids; - raw_spin_lock_init(&rt_rq->push_lock); - init_irq_work(&rt_rq->push_work, push_irq_work_func); -#endif #endif /* CONFIG_SMP */ /* We start is dequeued state, because no RT tasks are queued */ rt_rq->rt_queued = 0; @@ -1875,241 +1864,166 @@ static void push_rt_tasks(struct rq *rq) } #ifdef HAVE_RT_PUSH_IPI + /* - * The search for the next cpu always starts at rq->cpu and ends - * when we reach rq->cpu again. It will never return rq->cpu. - * This returns the next cpu to check, or nr_cpu_ids if the loop - * is complete. + * When a high priority task schedules out from a CPU and a lower priority + * task is scheduled in, a check is made to see if there's any RT tasks + * on other CPUs that are waiting to run because a higher priority RT task + * is currently running on its CPU. In this case, the CPU with multiple RT + * tasks queued on it (overloaded) needs to be notified that a CPU has opened + * up that may be able to run one of its non-running queued RT tasks. + * + * All CPUs with overloaded RT tasks need to be notified as there is currently + * no way to know which of these CPUs have the highest priority task waiting + * to run. Instead of trying to take a spinlock on each of these CPUs, + * which has shown to cause large latency when done on machines with many + * CPUs, sending an IPI to the CPUs to have them push off the overloaded + * RT tasks waiting to run. + * + * Just sending an IPI to each of the CPUs is also an issue, as on large + * count CPU machines, this can cause an IPI storm on a CPU, especially + * if its the only CPU with multiple RT tasks queued, and a large number + * of CPUs scheduling a lower priority task at the same time. + * + * Each root domain has its own irq work function that can iterate over + * all CPUs with RT overloaded tasks. Since all CPUs with overloaded RT + * tassk must be checked if there's one or many CPUs that are lowering + * their priority, there's a single irq work iterator that will try to + * push off RT tasks that are waiting to run. + * + * When a CPU schedules a lower priority task, it will kick off the + * irq work iterator that will jump to each CPU with overloaded RT tasks. + * As it only takes the first CPU that schedules a lower priority task + * to start the process, the rto_start variable is incremented and if + * the atomic result is one, then that CPU will try to take the rto_lock. + * This prevents high contention on the lock as the process handles all + * CPUs scheduling lower priority tasks. + * + * All CPUs that are scheduling a lower priority task will increment the + * rt_loop_next variable. This will make sure that the irq work iterator + * checks all RT overloaded CPUs whenever a CPU schedules a new lower + * priority task, even if the iterator is in the middle of a scan. Incrementing + * the rt_loop_next will cause the iterator to perform another scan. * - * rq->rt.push_cpu holds the last cpu returned by this function, - * or if this is the first instance, it must hold rq->cpu. */ static int rto_next_cpu(struct rq *rq) { - int prev_cpu = rq->rt.push_cpu; + struct root_domain *rd = rq->rd; + int next; int cpu; - cpu = cpumask_next(prev_cpu, rq->rd->rto_mask); - /* - * If the previous cpu is less than the rq's CPU, then it already - * passed the end of the mask, and has started from the beginning. - * We end if the next CPU is greater or equal to rq's CPU. + * When starting the IPI RT pushing, the rto_cpu is set to -1, + * rt_next_cpu() will simply return the first CPU found in + * the rto_mask. + * + * If rto_next_cpu() is called with rto_cpu is a valid cpu, it + * will return the next CPU found in the rto_mask. + * + * If there are no more CPUs left in the rto_mask, then a check is made + * against rto_loop and rto_loop_next. rto_loop is only updated with + * the rto_lock held, but any CPU may increment the rto_loop_next + * without any locking. */ - if (prev_cpu < rq->cpu) { - if (cpu >= rq->cpu) - return nr_cpu_ids; + for (;;) { - } else if (cpu >= nr_cpu_ids) { - /* - * We passed the end of the mask, start at the beginning. - * If the result is greater or equal to the rq's CPU, then - * the loop is finished. - */ - cpu = cpumask_first(rq->rd->rto_mask); - if (cpu >= rq->cpu) - return nr_cpu_ids; - } - rq->rt.push_cpu = cpu; + /* When rto_cpu is -1 this acts like cpumask_first() */ + cpu = cpumask_next(rd->rto_cpu, rd->rto_mask); - /* Return cpu to let the caller know if the loop is finished or not */ - return cpu; -} + rd->rto_cpu = cpu; -static int find_next_push_cpu(struct rq *rq) -{ - struct rq *next_rq; - int cpu; + if (cpu < nr_cpu_ids) + return cpu; - while (1) { - cpu = rto_next_cpu(rq); - if (cpu >= nr_cpu_ids) - break; - next_rq = cpu_rq(cpu); + rd->rto_cpu = -1; + + /* + * ACQUIRE ensures we see the @rto_mask changes + * made prior to the @next value observed. + * + * Matches WMB in rt_set_overload(). + */ + next = atomic_read_acquire(&rd->rto_loop_next); - /* Make sure the next rq can push to this rq */ - if (next_rq->rt.highest_prio.next < rq->rt.highest_prio.curr) + if (rd->rto_loop == next) break; + + rd->rto_loop = next; } - return cpu; + return -1; } -#define RT_PUSH_IPI_EXECUTING 1 -#define RT_PUSH_IPI_RESTART 2 +static inline bool rto_start_trylock(atomic_t *v) +{ + return !atomic_cmpxchg_acquire(v, 0, 1); +} -/* - * When a high priority task schedules out from a CPU and a lower priority - * task is scheduled in, a check is made to see if there's any RT tasks - * on other CPUs that are waiting to run because a higher priority RT task - * is currently running on its CPU. In this case, the CPU with multiple RT - * tasks queued on it (overloaded) needs to be notified that a CPU has opened - * up that may be able to run one of its non-running queued RT tasks. - * - * On large CPU boxes, there's the case that several CPUs could schedule - * a lower priority task at the same time, in which case it will look for - * any overloaded CPUs that it could pull a task from. To do this, the runqueue - * lock must be taken from that overloaded CPU. Having 10s of CPUs all fighting - * for a single overloaded CPU's runqueue lock can produce a large latency. - * (This has actually been observed on large boxes running cyclictest). - * Instead of taking the runqueue lock of the overloaded CPU, each of the - * CPUs that scheduled a lower priority task simply sends an IPI to the - * overloaded CPU. An IPI is much cheaper than taking an runqueue lock with - * lots of contention. The overloaded CPU will look to push its non-running - * RT task off, and if it does, it can then ignore the other IPIs coming - * in, and just pass those IPIs off to any other overloaded CPU. - * - * When a CPU schedules a lower priority task, it only sends an IPI to - * the "next" CPU that has overloaded RT tasks. This prevents IPI storms, - * as having 10 CPUs scheduling lower priority tasks and 10 CPUs with - * RT overloaded tasks, would cause 100 IPIs to go out at once. - * - * The overloaded RT CPU, when receiving an IPI, will try to push off its - * overloaded RT tasks and then send an IPI to the next CPU that has - * overloaded RT tasks. This stops when all CPUs with overloaded RT tasks - * have completed. Just because a CPU may have pushed off its own overloaded - * RT task does not mean it should stop sending the IPI around to other - * overloaded CPUs. There may be another RT task waiting to run on one of - * those CPUs that are of higher priority than the one that was just - * pushed. - * - * An optimization that could possibly be made is to make a CPU array similar - * to the cpupri array mask of all running RT tasks, but for the overloaded - * case, then the IPI could be sent to only the CPU with the highest priority - * RT task waiting, and that CPU could send off further IPIs to the CPU with - * the next highest waiting task. Since the overloaded case is much less likely - * to happen, the complexity of this implementation may not be worth it. - * Instead, just send an IPI around to all overloaded CPUs. - * - * The rq->rt.push_flags holds the status of the IPI that is going around. - * A run queue can only send out a single IPI at a time. The possible flags - * for rq->rt.push_flags are: - * - * (None or zero): No IPI is going around for the current rq - * RT_PUSH_IPI_EXECUTING: An IPI for the rq is being passed around - * RT_PUSH_IPI_RESTART: The priority of the running task for the rq - * has changed, and the IPI should restart - * circulating the overloaded CPUs again. - * - * rq->rt.push_cpu contains the CPU that is being sent the IPI. It is updated - * before sending to the next CPU. - * - * Instead of having all CPUs that schedule a lower priority task send - * an IPI to the same "first" CPU in the RT overload mask, they send it - * to the next overloaded CPU after their own CPU. This helps distribute - * the work when there's more than one overloaded CPU and multiple CPUs - * scheduling in lower priority tasks. - * - * When a rq schedules a lower priority task than what was currently - * running, the next CPU with overloaded RT tasks is examined first. - * That is, if CPU 1 and 5 are overloaded, and CPU 3 schedules a lower - * priority task, it will send an IPI first to CPU 5, then CPU 5 will - * send to CPU 1 if it is still overloaded. CPU 1 will clear the - * rq->rt.push_flags if RT_PUSH_IPI_RESTART is not set. - * - * The first CPU to notice IPI_RESTART is set, will clear that flag and then - * send an IPI to the next overloaded CPU after the rq->cpu and not the next - * CPU after push_cpu. That is, if CPU 1, 4 and 5 are overloaded when CPU 3 - * schedules a lower priority task, and the IPI_RESTART gets set while the - * handling is being done on CPU 5, it will clear the flag and send it back to - * CPU 4 instead of CPU 1. - * - * Note, the above logic can be disabled by turning off the sched_feature - * RT_PUSH_IPI. Then the rq lock of the overloaded CPU will simply be - * taken by the CPU requesting a pull and the waiting RT task will be pulled - * by that CPU. This may be fine for machines with few CPUs. - */ -static void tell_cpu_to_push(struct rq *rq) +static inline void rto_start_unlock(atomic_t *v) { - int cpu; + atomic_set_release(v, 0); +} - if (rq->rt.push_flags & RT_PUSH_IPI_EXECUTING) { - raw_spin_lock(&rq->rt.push_lock); - /* Make sure it's still executing */ - if (rq->rt.push_flags & RT_PUSH_IPI_EXECUTING) { - /* - * Tell the IPI to restart the loop as things have - * changed since it started. - */ - rq->rt.push_flags |= RT_PUSH_IPI_RESTART; - raw_spin_unlock(&rq->rt.push_lock); - return; - } - raw_spin_unlock(&rq->rt.push_lock); - } +static void tell_cpu_to_push(struct rq *rq) +{ + int cpu = -1; - /* When here, there's no IPI going around */ + /* Keep the loop going if the IPI is currently active */ + atomic_inc(&rq->rd->rto_loop_next); - rq->rt.push_cpu = rq->cpu; - cpu = find_next_push_cpu(rq); - if (cpu >= nr_cpu_ids) + /* Only one CPU can initiate a loop at a time */ + if (!rto_start_trylock(&rq->rd->rto_loop_start)) return; - rq->rt.push_flags = RT_PUSH_IPI_EXECUTING; + raw_spin_lock(&rq->rd->rto_lock); + + /* + * The rto_cpu is updated under the lock, if it has a valid cpu + * then the IPI is still running and will continue due to the + * update to loop_next, and nothing needs to be done here. + * Otherwise it is finishing up and an ipi needs to be sent. + */ + if (rq->rd->rto_cpu < 0) + cpu = rto_next_cpu(rq); - irq_work_queue_on(&rq->rt.push_work, cpu); + raw_spin_unlock(&rq->rd->rto_lock); + + rto_start_unlock(&rq->rd->rto_loop_start); + + if (cpu >= 0) + irq_work_queue_on(&rq->rd->rto_push_work, cpu); } /* Called from hardirq context */ -static void try_to_push_tasks(void *arg) +void rto_push_irq_work_func(struct irq_work *work) { - struct rt_rq *rt_rq = arg; - struct rq *rq, *src_rq; - int this_cpu; + struct rq *rq; int cpu; - this_cpu = rt_rq->push_cpu; + rq = this_rq(); - /* Paranoid check */ - BUG_ON(this_cpu != smp_processor_id()); - - rq = cpu_rq(this_cpu); - src_rq = rq_of_rt_rq(rt_rq); - -again: + /* + * We do not need to grab the lock to check for has_pushable_tasks. + * When it gets updated, a check is made if a push is possible. + */ if (has_pushable_tasks(rq)) { raw_spin_lock(&rq->lock); - push_rt_task(rq); + push_rt_tasks(rq); raw_spin_unlock(&rq->lock); } - /* Pass the IPI to the next rt overloaded queue */ - raw_spin_lock(&rt_rq->push_lock); - /* - * If the source queue changed since the IPI went out, - * we need to restart the search from that CPU again. - */ - if (rt_rq->push_flags & RT_PUSH_IPI_RESTART) { - rt_rq->push_flags &= ~RT_PUSH_IPI_RESTART; - rt_rq->push_cpu = src_rq->cpu; - } + raw_spin_lock(&rq->rd->rto_lock); - cpu = find_next_push_cpu(src_rq); + /* Pass the IPI to the next rt overloaded queue */ + cpu = rto_next_cpu(rq); - if (cpu >= nr_cpu_ids) - rt_rq->push_flags &= ~RT_PUSH_IPI_EXECUTING; - raw_spin_unlock(&rt_rq->push_lock); + raw_spin_unlock(&rq->rd->rto_lock); - if (cpu >= nr_cpu_ids) + if (cpu < 0) return; - /* - * It is possible that a restart caused this CPU to be - * chosen again. Don't bother with an IPI, just see if we - * have more to push. - */ - if (unlikely(cpu == rq->cpu)) - goto again; - /* Try the next RT overloaded CPU */ - irq_work_queue_on(&rt_rq->push_work, cpu); -} - -static void push_irq_work_func(struct irq_work *work) -{ - struct rt_rq *rt_rq = container_of(work, struct rt_rq, push_work); - - try_to_push_tasks(rt_rq); + irq_work_queue_on(&rq->rd->rto_push_work, cpu); } #endif /* HAVE_RT_PUSH_IPI */ diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h index a81c9782e98c..8aa24b41f652 100644 --- a/kernel/sched/sched.h +++ b/kernel/sched/sched.h @@ -505,7 +505,7 @@ static inline int rt_bandwidth_enabled(void) } /* RT IPI pull logic requires IRQ_WORK */ -#ifdef CONFIG_IRQ_WORK +#if defined(CONFIG_IRQ_WORK) && defined(CONFIG_SMP) # define HAVE_RT_PUSH_IPI #endif @@ -527,12 +527,6 @@ struct rt_rq { unsigned long rt_nr_total; int overloaded; struct plist_head pushable_tasks; -#ifdef HAVE_RT_PUSH_IPI - int push_flags; - int push_cpu; - struct irq_work push_work; - raw_spinlock_t push_lock; -#endif #endif /* CONFIG_SMP */ int rt_queued; @@ -641,6 +635,19 @@ struct root_domain { struct dl_bw dl_bw; struct cpudl cpudl; +#ifdef HAVE_RT_PUSH_IPI + /* + * For IPI pull requests, loop across the rto_mask. + */ + struct irq_work rto_push_work; + raw_spinlock_t rto_lock; + /* These are only updated and read within rto_lock */ + int rto_loop; + int rto_cpu; + /* These atomics are updated outside of a lock */ + atomic_t rto_loop_next; + atomic_t rto_loop_start; +#endif /* * The "RT overload" flag: it gets set if a CPU has more than * one runnable RT task. @@ -658,6 +665,9 @@ extern void init_defrootdomain(void); extern int sched_init_domains(const struct cpumask *cpu_map); extern void rq_attach_root(struct rq *rq, struct root_domain *rd); +#ifdef HAVE_RT_PUSH_IPI +extern void rto_push_irq_work_func(struct irq_work *work); +#endif #endif /* CONFIG_SMP */ /* diff --git a/kernel/sched/topology.c b/kernel/sched/topology.c index f51d123f9fe1..e50450c2fed8 100644 --- a/kernel/sched/topology.c +++ b/kernel/sched/topology.c @@ -268,6 +268,12 @@ static int init_rootdomain(struct root_domain *rd) if (!zalloc_cpumask_var(&rd->rto_mask, GFP_KERNEL)) goto free_dlo_mask; +#ifdef HAVE_RT_PUSH_IPI + rd->rto_cpu = -1; + raw_spin_lock_init(&rd->rto_lock); + init_irq_work(&rd->rto_push_work, rto_push_irq_work_func); +#endif + init_dl_bw(&rd->dl_bw); if (cpudl_init(&rd->cpudl) != 0) goto free_rto_mask;

7 years, 5 months

3
3
0 0

[Linux-stable-mirror] [PATCH v2] drm/i915/gvt: Correct ADDR_4K/2M/1G_MASK definition

by Xiong Zhang

For ADDR_4K_MASK, bit[45..12] should be 1, all other bits should be 0. The current definition wrongly set bit[46] as 1 also. This path fixes this. v2: Add commit message, fixes and cc stable.(Zhenyu) Fixes: 2707e4446688("drm/i915/gvt: vGPU graphics memory virtualization") Signed-off-by: Xiong Zhang <xiong.y.zhang(a)intel.com> Cc: stable(a)vger.kernel.org --- drivers/gpu/drm/i915/gvt/gtt.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/gvt/gtt.c b/drivers/gpu/drm/i915/gvt/gtt.c index 3d6008b..71a0f2b 100644 --- a/drivers/gpu/drm/i915/gvt/gtt.c +++ b/drivers/gpu/drm/i915/gvt/gtt.c @@ -331,9 +331,9 @@ static inline int gtt_set_entry64(void *pt, #define GTT_HAW 46 -#define ADDR_1G_MASK (((1UL << (GTT_HAW - 30 + 1)) - 1) << 30) -#define ADDR_2M_MASK (((1UL << (GTT_HAW - 21 + 1)) - 1) << 21) -#define ADDR_4K_MASK (((1UL << (GTT_HAW - 12 + 1)) - 1) << 12) +#define ADDR_1G_MASK (((1UL << (GTT_HAW - 30)) - 1) << 30) +#define ADDR_2M_MASK (((1UL << (GTT_HAW - 21)) - 1) << 21) +#define ADDR_4K_MASK (((1UL << (GTT_HAW - 12)) - 1) << 12) static unsigned long gen8_gtt_get_pfn(struct intel_gvt_gtt_entry *e) { -- 2.7.4

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] + mmmadvise-bugfix-of-madvise-systemcall-infinite-loop-under-special-circumstances.patch added to -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: mm/madvise.c: fix madvise() infinite loop under special circumstances has been added to the -mm tree. Its filename is mmmadvise-bugfix-of-madvise-systemcall-infinite-loop-under-special-circumstances.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/mmmadvise-bugfix-of-madvise-system… and later at http://ozlabs.org/~akpm/mmotm/broken-out/mmmadvise-bugfix-of-madvise-system… Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/SubmitChecklist when testing your code *** The -mm tree is included into linux-next and is updated there every 3-4 working days ------------------------------------------------------ From: chenjie <chenjie6(a)huawei.com> Subject: mm/madvise.c: fix madvise() infinite loop under special circumstances MADVISE_WILLNEED has always been a noop for DAX (formerly XIP) mappings. Unfortunatelly madvise_willneed() doesn't communicate this information properly to the generic madvise syscall implementation. The calling convention is quite subtle there. madvise_vma() is supposed to either return an error or update &prev otherwise the main loop will never advance to the next vma and it will keep looping for ever without a way to get out of the kernel. It seems this has been broken since introduction. Nobody has noticed because nobody seems to be using MADVISE_WILLNEED on these DAX mappings. [mhocko(a)suse.com: rewrite changelog] Link: http://lkml.kernel.org/r/20171127115318.911-1-guoxuenan@huawei.com Fixes: fe77ba6f4f97 ("[PATCH] xip: madvice/fadvice: execute in place") Signed-off-by: chenjie <chenjie6(a)huawei.com> Signed-off-by: guoxuenan <guoxuenan(a)huawei.com> Acked-by: Michal Hocko <mhocko(a)suse.com> Cc: Minchan Kim <minchan(a)kernel.org> Cc: zhangyi (F) <yi.zhang(a)huawei.com> Cc: Miao Xie <miaoxie(a)huawei.com> Cc: Mike Rapoport <rppt(a)linux.vnet.ibm.com> Cc: Shaohua Li <shli(a)fb.com> Cc: Andrea Arcangeli <aarcange(a)redhat.com> Cc: Mel Gorman <mgorman(a)techsingularity.net> Cc: Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com> Cc: David Rientjes <rientjes(a)google.com> Cc: Anshuman Khandual <khandual(a)linux.vnet.ibm.com> Cc: Rik van Riel <riel(a)redhat.com> Cc: Carsten Otte <cotte(a)de.ibm.com> Cc: Dan Williams <dan.j.williams(a)intel.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/madvise.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff -puN mm/madvise.c~mmmadvise-bugfix-of-madvise-systemcall-infinite-loop-under-special-circumstances mm/madvise.c --- a/mm/madvise.c~mmmadvise-bugfix-of-madvise-systemcall-infinite-loop-under-special-circumstances +++ a/mm/madvise.c @@ -276,15 +276,14 @@ static long madvise_willneed(struct vm_a { struct file *file = vma->vm_file; + *prev = vma; #ifdef CONFIG_SWAP if (!file) { - *prev = vma; force_swapin_readahead(vma, start, end); return 0; } if (shmem_mapping(file->f_mapping)) { - *prev = vma; force_shm_swapin_readahead(vma, start, end, file->f_mapping); return 0; @@ -299,7 +298,6 @@ static long madvise_willneed(struct vm_a return 0; } - *prev = vma; start = ((start - vma->vm_start) >> PAGE_SHIFT) + vma->vm_pgoff; if (end > vma->vm_end) end = vma->vm_end; _ Patches currently in -mm which might be from chenjie6(a)huawei.com are mmmadvise-bugfix-of-madvise-systemcall-infinite-loop-under-special-circumstances.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] + exec-avoid-rlimit_stack-races-with-prlimit.patch added to -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: exec: avoid RLIMIT_STACK races with prlimit() has been added to the -mm tree. Its filename is exec-avoid-rlimit_stack-races-with-prlimit.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/exec-avoid-rlimit_stack-races-with… and later at http://ozlabs.org/~akpm/mmotm/broken-out/exec-avoid-rlimit_stack-races-with… Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/SubmitChecklist when testing your code *** The -mm tree is included into linux-next and is updated there every 3-4 working days ------------------------------------------------------ From: Kees Cook <keescook(a)chromium.org> Subject: exec: avoid RLIMIT_STACK races with prlimit() While the defense-in-depth RLIMIT_STACK limit on setuid processes was protected against races from other threads calling setrlimit(), I missed protecting it against races from external processes calling prlimit(). This adds locking around the change and makes sure that rlim_max is set too. Link: http://lkml.kernel.org/r/20171127193457.GA11348@beast Fixes: 64701dee4178e ("exec: Use sane stack rlimit under secureexec") Signed-off-by: Kees Cook <keescook(a)chromium.org> Reported-by: Ben Hutchings <ben.hutchings(a)codethink.co.uk> Reported-by: Brad Spengler <spender(a)grsecurity.net> Cc: James Morris <james.l.morris(a)oracle.com> Cc: Serge Hallyn <serge(a)hallyn.com> Cc: Andy Lutomirski <luto(a)kernel.org> Cc: Oleg Nesterov <oleg(a)redhat.com> Cc: Jiri Slaby <jslaby(a)suse.cz> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- fs/exec.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff -puN fs/exec.c~exec-avoid-rlimit_stack-races-with-prlimit fs/exec.c --- a/fs/exec.c~exec-avoid-rlimit_stack-races-with-prlimit +++ a/fs/exec.c @@ -1340,10 +1340,15 @@ void setup_new_exec(struct linux_binprm * avoid bad behavior from the prior rlimits. This has to * happen before arch_pick_mmap_layout(), which examines * RLIMIT_STACK, but after the point of no return to avoid - * needing to clean up the change on failure. + * races from other threads changing the limits. This also + * must be protected from races with prlimit() calls. */ + task_lock(current->group_leader); if (current->signal->rlim[RLIMIT_STACK].rlim_cur > _STK_LIM) current->signal->rlim[RLIMIT_STACK].rlim_cur = _STK_LIM; + if (current->signal->rlim[RLIMIT_STACK].rlim_max > _STK_LIM) + current->signal->rlim[RLIMIT_STACK].rlim_max = _STK_LIM; + task_unlock(current->group_leader); } arch_pick_mmap_layout(current->mm); _ Patches currently in -mm which might be from keescook(a)chromium.org are exec-avoid-rlimit_stack-races-with-prlimit.patch makefile-move-stack-protector-compiler-breakage-test-earlier.patch makefile-move-stack-protector-availability-out-of-kconfig.patch makefile-introduce-config_cc_stackprotector_auto.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] [PATCH v2] drm/i915/gvt: Correct ADDR_4K/2M/1G_MASK definition

by Xiong Zhang

For ADDR_4K_MASK, bit[45..12] should be 1, all other bits should be 0. The current definition wrongly set bit[46] as 1 also. This path fixes this. v2: Add commit message, fixes and cc stable.(Zhenyu) Fixes: 2707e4446688("drm/i915/gvt: vGPU graphics memory virtualization") Signed-off-by: Xiong Zhang <xiong.y.zhang(a)intel.com> --- drivers/gpu/drm/i915/gvt/gtt.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/gvt/gtt.c b/drivers/gpu/drm/i915/gvt/gtt.c index 3d6008b..71a0f2b 100644 --- a/drivers/gpu/drm/i915/gvt/gtt.c +++ b/drivers/gpu/drm/i915/gvt/gtt.c @@ -331,9 +331,9 @@ static inline int gtt_set_entry64(void *pt, #define GTT_HAW 46 -#define ADDR_1G_MASK (((1UL << (GTT_HAW - 30 + 1)) - 1) << 30) -#define ADDR_2M_MASK (((1UL << (GTT_HAW - 21 + 1)) - 1) << 21) -#define ADDR_4K_MASK (((1UL << (GTT_HAW - 12 + 1)) - 1) << 12) +#define ADDR_1G_MASK (((1UL << (GTT_HAW - 30)) - 1) << 30) +#define ADDR_2M_MASK (((1UL << (GTT_HAW - 21)) - 1) << 21) +#define ADDR_4K_MASK (((1UL << (GTT_HAW - 12)) - 1) << 12) static unsigned long gen8_gtt_get_pfn(struct intel_gvt_gtt_entry *e) { -- 2.7.4

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] [PATCH 4.1] fscrypt: lock mutex before checking for bounce page pool

by Eric Biggers

commit a0b3bc855374c50b5ea85273553485af48caf2f7 upstream. [Please apply to 4.1-stable.] fscrypt_initialize(), which allocates the global bounce page pool when an encrypted file is first accessed, uses "double-checked locking" to try to avoid locking fscrypt_init_mutex. However, it doesn't use any memory barriers, so it's theoretically possible for a thread to observe a bounce page pool which has not been fully initialized. This is a classic bug with "double-checked locking". While "only a theoretical issue" in the latest kernel, in pre-4.8 kernels the pointer that was checked was not even the last to be initialized, so it was easily possible for a crash (NULL pointer dereference) to happen. This was changed only incidentally by the large refactor to use fs/crypto/. Solve both problems in a trivial way that can easily be backported: just always take the mutex. It's theoretically less efficient, but it shouldn't be noticeable in practice as the mutex is only acquired very briefly once per encrypted file. Later I'd like to make this use a helper macro like DO_ONCE(). However, DO_ONCE() runs in atomic context, so we'd need to add a new macro that allows blocking. Cc: stable(a)vger.kernel.org # v4.1+ Signed-off-by: Eric Biggers <ebiggers(a)google.com> Signed-off-by: Theodore Ts'o <tytso(a)mit.edu> --- fs/ext4/crypto.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/fs/ext4/crypto.c b/fs/ext4/crypto.c index 8ff15273ab0c..fdda7a5a1180 100644 --- a/fs/ext4/crypto.c +++ b/fs/ext4/crypto.c @@ -120,8 +120,7 @@ struct ext4_crypto_ctx *ext4_get_crypto_ctx(struct inode *inode) unsigned long flags; struct ext4_encryption_key *key = &EXT4_I(inode)->i_encryption_key; - if (!ext4_read_workqueue) - ext4_init_crypto(); + ext4_init_crypto(); /* * We first try getting the ctx from a free list because in -- 2.15.0.417.g466bffb3ac-goog

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] [PATCH] eeprom: at24: fix the magic value for at24mac402

by Bartosz Golaszewski

There's an ilog2() expansion in AT24_DEVICE_MAGIC() which rounds down the actual size of EUI-48 byte array in at24mac402 eeproms to 4 from 6, making it impossible to read it all. Fix it by creating the magic value manually with the correct size. This patch contains a temporary fix that is suitable for stable branches. Eventually we'll probably remove the call to ilog2() while converting the magic values to actual structs. This fix will cause a warning message to be emitted by probe() for at24mac402 chips but theys should be initialized correctly anyway. Cc: stable(a)vger.kernel.org Fixes: 0b813658c115 ("eeprom: at24: add support for at24mac series") Signed-off-by: Bartosz Golaszewski <brgl(a)bgdev.pl> --- drivers/misc/eeprom/at24.c | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/drivers/misc/eeprom/at24.c b/drivers/misc/eeprom/at24.c index e0b4b36ef010..72adf34627f5 100644 --- a/drivers/misc/eeprom/at24.c +++ b/drivers/misc/eeprom/at24.c @@ -141,8 +141,17 @@ static const struct i2c_device_id at24_ids[] = { { "24c02", AT24_DEVICE_MAGIC(2048 / 8, 0) }, { "24cs02", AT24_DEVICE_MAGIC(16, AT24_FLAG_SERIAL | AT24_FLAG_READONLY) }, - { "24mac402", AT24_DEVICE_MAGIC(48 / 8, - AT24_FLAG_MAC | AT24_FLAG_READONLY) }, + /* + * REVISIT: the size of the EUI-48 byte array is 6 in at24mac402, while + * the call to ilog2() in AT24_DEVICE_MAGIC() rounds it down to 4. We + * might want to eventually remove it altogether or maybe even convert + * the magic values to real structs. + * + * For now just create the magic value manually with the right size. + */ + { "24mac402", ((1 << AT24_SIZE_FLAGS | + (AT24_FLAG_MAC | AT24_FLAG_READONLY)) + << AT24_SIZE_BYTELEN | (48 / 8)) }, { "24mac602", AT24_DEVICE_MAGIC(64 / 8, AT24_FLAG_MAC | AT24_FLAG_READONLY) }, /* spd is a 24c02 in memory DIMMs */ -- 2.15.0

7 years, 5 months

2
2
0 0

[Linux-stable-mirror] FAILED: patch "[PATCH] sched/rt: Simplify the IPI based RT balancing logic" failed to apply to 3.18-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 3.18-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 4bdced5c9a2922521e325896a7bbbf0132c94e56 Mon Sep 17 00:00:00 2001 From: "Steven Rostedt (Red Hat)" <rostedt(a)goodmis.org> Date: Fri, 6 Oct 2017 14:05:04 -0400 Subject: [PATCH] sched/rt: Simplify the IPI based RT balancing logic When a CPU lowers its priority (schedules out a high priority task for a lower priority one), a check is made to see if any other CPU has overloaded RT tasks (more than one). It checks the rto_mask to determine this and if so it will request to pull one of those tasks to itself if the non running RT task is of higher priority than the new priority of the next task to run on the current CPU. When we deal with large number of CPUs, the original pull logic suffered from large lock contention on a single CPU run queue, which caused a huge latency across all CPUs. This was caused by only having one CPU having overloaded RT tasks and a bunch of other CPUs lowering their priority. To solve this issue, commit: b6366f048e0c ("sched/rt: Use IPI to trigger RT task push migration instead of pulling") changed the way to request a pull. Instead of grabbing the lock of the overloaded CPU's runqueue, it simply sent an IPI to that CPU to do the work. Although the IPI logic worked very well in removing the large latency build up, it still could suffer from a large number of IPIs being sent to a single CPU. On a 80 CPU box, I measured over 200us of processing IPIs. Worse yet, when I tested this on a 120 CPU box, with a stress test that had lots of RT tasks scheduling on all CPUs, it actually triggered the hard lockup detector! One CPU had so many IPIs sent to it, and due to the restart mechanism that is triggered when the source run queue has a priority status change, the CPU spent minutes! processing the IPIs. Thinking about this further, I realized there's no reason for each run queue to send its own IPI. As all CPUs with overloaded tasks must be scanned regardless if there's one or many CPUs lowering their priority, because there's no current way to find the CPU with the highest priority task that can schedule to one of these CPUs, there really only needs to be one IPI being sent around at a time. This greatly simplifies the code! The new approach is to have each root domain have its own irq work, as the rto_mask is per root domain. The root domain has the following fields attached to it: rto_push_work - the irq work to process each CPU set in rto_mask rto_lock - the lock to protect some of the other rto fields rto_loop_start - an atomic that keeps contention down on rto_lock the first CPU scheduling in a lower priority task is the one to kick off the process. rto_loop_next - an atomic that gets incremented for each CPU that schedules in a lower priority task. rto_loop - a variable protected by rto_lock that is used to compare against rto_loop_next rto_cpu - The cpu to send the next IPI to, also protected by the rto_lock. When a CPU schedules in a lower priority task and wants to make sure overloaded CPUs know about it. It increments the rto_loop_next. Then it atomically sets rto_loop_start with a cmpxchg. If the old value is not "0", then it is done, as another CPU is kicking off the IPI loop. If the old value is "0", then it will take the rto_lock to synchronize with a possible IPI being sent around to the overloaded CPUs. If rto_cpu is greater than or equal to nr_cpu_ids, then there's either no IPI being sent around, or one is about to finish. Then rto_cpu is set to the first CPU in rto_mask and an IPI is sent to that CPU. If there's no CPUs set in rto_mask, then there's nothing to be done. When the CPU receives the IPI, it will first try to push any RT tasks that is queued on the CPU but can't run because a higher priority RT task is currently running on that CPU. Then it takes the rto_lock and looks for the next CPU in the rto_mask. If it finds one, it simply sends an IPI to that CPU and the process continues. If there's no more CPUs in the rto_mask, then rto_loop is compared with rto_loop_next. If they match, everything is done and the process is over. If they do not match, then a CPU scheduled in a lower priority task as the IPI was being passed around, and the process needs to start again. The first CPU in rto_mask is sent the IPI. This change removes this duplication of work in the IPI logic, and greatly lowers the latency caused by the IPIs. This removed the lockup happening on the 120 CPU machine. It also simplifies the code tremendously. What else could anyone ask for? Thanks to Peter Zijlstra for simplifying the rto_loop_start atomic logic and supplying me with the rto_start_trylock() and rto_start_unlock() helper functions. Signed-off-by: Steven Rostedt (VMware) <rostedt(a)goodmis.org> Signed-off-by: Peter Zijlstra (Intel) <peterz(a)infradead.org> Cc: Clark Williams <williams(a)redhat.com> Cc: Daniel Bristot de Oliveira <bristot(a)redhat.com> Cc: John Kacur <jkacur(a)redhat.com> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Mike Galbraith <efault(a)gmx.de> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Scott Wood <swood(a)redhat.com> Cc: Thomas Gleixner <tglx(a)linutronix.de> Link: http://lkml.kernel.org/r/20170424114732.1aac6dc4@gandalf.local.home Signed-off-by: Ingo Molnar <mingo(a)kernel.org> diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c index 0af5ca9e3e3f..fda27991699a 100644 --- a/kernel/sched/rt.c +++ b/kernel/sched/rt.c @@ -73,10 +73,6 @@ static void start_rt_bandwidth(struct rt_bandwidth *rt_b) raw_spin_unlock(&rt_b->rt_runtime_lock); } -#if defined(CONFIG_SMP) && defined(HAVE_RT_PUSH_IPI) -static void push_irq_work_func(struct irq_work *work); -#endif - void init_rt_rq(struct rt_rq *rt_rq) { struct rt_prio_array *array; @@ -96,13 +92,6 @@ void init_rt_rq(struct rt_rq *rt_rq) rt_rq->rt_nr_migratory = 0; rt_rq->overloaded = 0; plist_head_init(&rt_rq->pushable_tasks); - -#ifdef HAVE_RT_PUSH_IPI - rt_rq->push_flags = 0; - rt_rq->push_cpu = nr_cpu_ids; - raw_spin_lock_init(&rt_rq->push_lock); - init_irq_work(&rt_rq->push_work, push_irq_work_func); -#endif #endif /* CONFIG_SMP */ /* We start is dequeued state, because no RT tasks are queued */ rt_rq->rt_queued = 0; @@ -1875,241 +1864,166 @@ static void push_rt_tasks(struct rq *rq) } #ifdef HAVE_RT_PUSH_IPI + /* - * The search for the next cpu always starts at rq->cpu and ends - * when we reach rq->cpu again. It will never return rq->cpu. - * This returns the next cpu to check, or nr_cpu_ids if the loop - * is complete. + * When a high priority task schedules out from a CPU and a lower priority + * task is scheduled in, a check is made to see if there's any RT tasks + * on other CPUs that are waiting to run because a higher priority RT task + * is currently running on its CPU. In this case, the CPU with multiple RT + * tasks queued on it (overloaded) needs to be notified that a CPU has opened + * up that may be able to run one of its non-running queued RT tasks. + * + * All CPUs with overloaded RT tasks need to be notified as there is currently + * no way to know which of these CPUs have the highest priority task waiting + * to run. Instead of trying to take a spinlock on each of these CPUs, + * which has shown to cause large latency when done on machines with many + * CPUs, sending an IPI to the CPUs to have them push off the overloaded + * RT tasks waiting to run. + * + * Just sending an IPI to each of the CPUs is also an issue, as on large + * count CPU machines, this can cause an IPI storm on a CPU, especially + * if its the only CPU with multiple RT tasks queued, and a large number + * of CPUs scheduling a lower priority task at the same time. + * + * Each root domain has its own irq work function that can iterate over + * all CPUs with RT overloaded tasks. Since all CPUs with overloaded RT + * tassk must be checked if there's one or many CPUs that are lowering + * their priority, there's a single irq work iterator that will try to + * push off RT tasks that are waiting to run. + * + * When a CPU schedules a lower priority task, it will kick off the + * irq work iterator that will jump to each CPU with overloaded RT tasks. + * As it only takes the first CPU that schedules a lower priority task + * to start the process, the rto_start variable is incremented and if + * the atomic result is one, then that CPU will try to take the rto_lock. + * This prevents high contention on the lock as the process handles all + * CPUs scheduling lower priority tasks. + * + * All CPUs that are scheduling a lower priority task will increment the + * rt_loop_next variable. This will make sure that the irq work iterator + * checks all RT overloaded CPUs whenever a CPU schedules a new lower + * priority task, even if the iterator is in the middle of a scan. Incrementing + * the rt_loop_next will cause the iterator to perform another scan. * - * rq->rt.push_cpu holds the last cpu returned by this function, - * or if this is the first instance, it must hold rq->cpu. */ static int rto_next_cpu(struct rq *rq) { - int prev_cpu = rq->rt.push_cpu; + struct root_domain *rd = rq->rd; + int next; int cpu; - cpu = cpumask_next(prev_cpu, rq->rd->rto_mask); - /* - * If the previous cpu is less than the rq's CPU, then it already - * passed the end of the mask, and has started from the beginning. - * We end if the next CPU is greater or equal to rq's CPU. + * When starting the IPI RT pushing, the rto_cpu is set to -1, + * rt_next_cpu() will simply return the first CPU found in + * the rto_mask. + * + * If rto_next_cpu() is called with rto_cpu is a valid cpu, it + * will return the next CPU found in the rto_mask. + * + * If there are no more CPUs left in the rto_mask, then a check is made + * against rto_loop and rto_loop_next. rto_loop is only updated with + * the rto_lock held, but any CPU may increment the rto_loop_next + * without any locking. */ - if (prev_cpu < rq->cpu) { - if (cpu >= rq->cpu) - return nr_cpu_ids; + for (;;) { - } else if (cpu >= nr_cpu_ids) { - /* - * We passed the end of the mask, start at the beginning. - * If the result is greater or equal to the rq's CPU, then - * the loop is finished. - */ - cpu = cpumask_first(rq->rd->rto_mask); - if (cpu >= rq->cpu) - return nr_cpu_ids; - } - rq->rt.push_cpu = cpu; + /* When rto_cpu is -1 this acts like cpumask_first() */ + cpu = cpumask_next(rd->rto_cpu, rd->rto_mask); - /* Return cpu to let the caller know if the loop is finished or not */ - return cpu; -} + rd->rto_cpu = cpu; -static int find_next_push_cpu(struct rq *rq) -{ - struct rq *next_rq; - int cpu; + if (cpu < nr_cpu_ids) + return cpu; - while (1) { - cpu = rto_next_cpu(rq); - if (cpu >= nr_cpu_ids) - break; - next_rq = cpu_rq(cpu); + rd->rto_cpu = -1; + + /* + * ACQUIRE ensures we see the @rto_mask changes + * made prior to the @next value observed. + * + * Matches WMB in rt_set_overload(). + */ + next = atomic_read_acquire(&rd->rto_loop_next); - /* Make sure the next rq can push to this rq */ - if (next_rq->rt.highest_prio.next < rq->rt.highest_prio.curr) + if (rd->rto_loop == next) break; + + rd->rto_loop = next; } - return cpu; + return -1; } -#define RT_PUSH_IPI_EXECUTING 1 -#define RT_PUSH_IPI_RESTART 2 +static inline bool rto_start_trylock(atomic_t *v) +{ + return !atomic_cmpxchg_acquire(v, 0, 1); +} -/* - * When a high priority task schedules out from a CPU and a lower priority - * task is scheduled in, a check is made to see if there's any RT tasks - * on other CPUs that are waiting to run because a higher priority RT task - * is currently running on its CPU. In this case, the CPU with multiple RT - * tasks queued on it (overloaded) needs to be notified that a CPU has opened - * up that may be able to run one of its non-running queued RT tasks. - * - * On large CPU boxes, there's the case that several CPUs could schedule - * a lower priority task at the same time, in which case it will look for - * any overloaded CPUs that it could pull a task from. To do this, the runqueue - * lock must be taken from that overloaded CPU. Having 10s of CPUs all fighting - * for a single overloaded CPU's runqueue lock can produce a large latency. - * (This has actually been observed on large boxes running cyclictest). - * Instead of taking the runqueue lock of the overloaded CPU, each of the - * CPUs that scheduled a lower priority task simply sends an IPI to the - * overloaded CPU. An IPI is much cheaper than taking an runqueue lock with - * lots of contention. The overloaded CPU will look to push its non-running - * RT task off, and if it does, it can then ignore the other IPIs coming - * in, and just pass those IPIs off to any other overloaded CPU. - * - * When a CPU schedules a lower priority task, it only sends an IPI to - * the "next" CPU that has overloaded RT tasks. This prevents IPI storms, - * as having 10 CPUs scheduling lower priority tasks and 10 CPUs with - * RT overloaded tasks, would cause 100 IPIs to go out at once. - * - * The overloaded RT CPU, when receiving an IPI, will try to push off its - * overloaded RT tasks and then send an IPI to the next CPU that has - * overloaded RT tasks. This stops when all CPUs with overloaded RT tasks - * have completed. Just because a CPU may have pushed off its own overloaded - * RT task does not mean it should stop sending the IPI around to other - * overloaded CPUs. There may be another RT task waiting to run on one of - * those CPUs that are of higher priority than the one that was just - * pushed. - * - * An optimization that could possibly be made is to make a CPU array similar - * to the cpupri array mask of all running RT tasks, but for the overloaded - * case, then the IPI could be sent to only the CPU with the highest priority - * RT task waiting, and that CPU could send off further IPIs to the CPU with - * the next highest waiting task. Since the overloaded case is much less likely - * to happen, the complexity of this implementation may not be worth it. - * Instead, just send an IPI around to all overloaded CPUs. - * - * The rq->rt.push_flags holds the status of the IPI that is going around. - * A run queue can only send out a single IPI at a time. The possible flags - * for rq->rt.push_flags are: - * - * (None or zero): No IPI is going around for the current rq - * RT_PUSH_IPI_EXECUTING: An IPI for the rq is being passed around - * RT_PUSH_IPI_RESTART: The priority of the running task for the rq - * has changed, and the IPI should restart - * circulating the overloaded CPUs again. - * - * rq->rt.push_cpu contains the CPU that is being sent the IPI. It is updated - * before sending to the next CPU. - * - * Instead of having all CPUs that schedule a lower priority task send - * an IPI to the same "first" CPU in the RT overload mask, they send it - * to the next overloaded CPU after their own CPU. This helps distribute - * the work when there's more than one overloaded CPU and multiple CPUs - * scheduling in lower priority tasks. - * - * When a rq schedules a lower priority task than what was currently - * running, the next CPU with overloaded RT tasks is examined first. - * That is, if CPU 1 and 5 are overloaded, and CPU 3 schedules a lower - * priority task, it will send an IPI first to CPU 5, then CPU 5 will - * send to CPU 1 if it is still overloaded. CPU 1 will clear the - * rq->rt.push_flags if RT_PUSH_IPI_RESTART is not set. - * - * The first CPU to notice IPI_RESTART is set, will clear that flag and then - * send an IPI to the next overloaded CPU after the rq->cpu and not the next - * CPU after push_cpu. That is, if CPU 1, 4 and 5 are overloaded when CPU 3 - * schedules a lower priority task, and the IPI_RESTART gets set while the - * handling is being done on CPU 5, it will clear the flag and send it back to - * CPU 4 instead of CPU 1. - * - * Note, the above logic can be disabled by turning off the sched_feature - * RT_PUSH_IPI. Then the rq lock of the overloaded CPU will simply be - * taken by the CPU requesting a pull and the waiting RT task will be pulled - * by that CPU. This may be fine for machines with few CPUs. - */ -static void tell_cpu_to_push(struct rq *rq) +static inline void rto_start_unlock(atomic_t *v) { - int cpu; + atomic_set_release(v, 0); +} - if (rq->rt.push_flags & RT_PUSH_IPI_EXECUTING) { - raw_spin_lock(&rq->rt.push_lock); - /* Make sure it's still executing */ - if (rq->rt.push_flags & RT_PUSH_IPI_EXECUTING) { - /* - * Tell the IPI to restart the loop as things have - * changed since it started. - */ - rq->rt.push_flags |= RT_PUSH_IPI_RESTART; - raw_spin_unlock(&rq->rt.push_lock); - return; - } - raw_spin_unlock(&rq->rt.push_lock); - } +static void tell_cpu_to_push(struct rq *rq) +{ + int cpu = -1; - /* When here, there's no IPI going around */ + /* Keep the loop going if the IPI is currently active */ + atomic_inc(&rq->rd->rto_loop_next); - rq->rt.push_cpu = rq->cpu; - cpu = find_next_push_cpu(rq); - if (cpu >= nr_cpu_ids) + /* Only one CPU can initiate a loop at a time */ + if (!rto_start_trylock(&rq->rd->rto_loop_start)) return; - rq->rt.push_flags = RT_PUSH_IPI_EXECUTING; + raw_spin_lock(&rq->rd->rto_lock); + + /* + * The rto_cpu is updated under the lock, if it has a valid cpu + * then the IPI is still running and will continue due to the + * update to loop_next, and nothing needs to be done here. + * Otherwise it is finishing up and an ipi needs to be sent. + */ + if (rq->rd->rto_cpu < 0) + cpu = rto_next_cpu(rq); - irq_work_queue_on(&rq->rt.push_work, cpu); + raw_spin_unlock(&rq->rd->rto_lock); + + rto_start_unlock(&rq->rd->rto_loop_start); + + if (cpu >= 0) + irq_work_queue_on(&rq->rd->rto_push_work, cpu); } /* Called from hardirq context */ -static void try_to_push_tasks(void *arg) +void rto_push_irq_work_func(struct irq_work *work) { - struct rt_rq *rt_rq = arg; - struct rq *rq, *src_rq; - int this_cpu; + struct rq *rq; int cpu; - this_cpu = rt_rq->push_cpu; + rq = this_rq(); - /* Paranoid check */ - BUG_ON(this_cpu != smp_processor_id()); - - rq = cpu_rq(this_cpu); - src_rq = rq_of_rt_rq(rt_rq); - -again: + /* + * We do not need to grab the lock to check for has_pushable_tasks. + * When it gets updated, a check is made if a push is possible. + */ if (has_pushable_tasks(rq)) { raw_spin_lock(&rq->lock); - push_rt_task(rq); + push_rt_tasks(rq); raw_spin_unlock(&rq->lock); } - /* Pass the IPI to the next rt overloaded queue */ - raw_spin_lock(&rt_rq->push_lock); - /* - * If the source queue changed since the IPI went out, - * we need to restart the search from that CPU again. - */ - if (rt_rq->push_flags & RT_PUSH_IPI_RESTART) { - rt_rq->push_flags &= ~RT_PUSH_IPI_RESTART; - rt_rq->push_cpu = src_rq->cpu; - } + raw_spin_lock(&rq->rd->rto_lock); - cpu = find_next_push_cpu(src_rq); + /* Pass the IPI to the next rt overloaded queue */ + cpu = rto_next_cpu(rq); - if (cpu >= nr_cpu_ids) - rt_rq->push_flags &= ~RT_PUSH_IPI_EXECUTING; - raw_spin_unlock(&rt_rq->push_lock); + raw_spin_unlock(&rq->rd->rto_lock); - if (cpu >= nr_cpu_ids) + if (cpu < 0) return; - /* - * It is possible that a restart caused this CPU to be - * chosen again. Don't bother with an IPI, just see if we - * have more to push. - */ - if (unlikely(cpu == rq->cpu)) - goto again; - /* Try the next RT overloaded CPU */ - irq_work_queue_on(&rt_rq->push_work, cpu); -} - -static void push_irq_work_func(struct irq_work *work) -{ - struct rt_rq *rt_rq = container_of(work, struct rt_rq, push_work); - - try_to_push_tasks(rt_rq); + irq_work_queue_on(&rq->rd->rto_push_work, cpu); } #endif /* HAVE_RT_PUSH_IPI */ diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h index a81c9782e98c..8aa24b41f652 100644 --- a/kernel/sched/sched.h +++ b/kernel/sched/sched.h @@ -505,7 +505,7 @@ static inline int rt_bandwidth_enabled(void) } /* RT IPI pull logic requires IRQ_WORK */ -#ifdef CONFIG_IRQ_WORK +#if defined(CONFIG_IRQ_WORK) && defined(CONFIG_SMP) # define HAVE_RT_PUSH_IPI #endif @@ -527,12 +527,6 @@ struct rt_rq { unsigned long rt_nr_total; int overloaded; struct plist_head pushable_tasks; -#ifdef HAVE_RT_PUSH_IPI - int push_flags; - int push_cpu; - struct irq_work push_work; - raw_spinlock_t push_lock; -#endif #endif /* CONFIG_SMP */ int rt_queued; @@ -641,6 +635,19 @@ struct root_domain { struct dl_bw dl_bw; struct cpudl cpudl; +#ifdef HAVE_RT_PUSH_IPI + /* + * For IPI pull requests, loop across the rto_mask. + */ + struct irq_work rto_push_work; + raw_spinlock_t rto_lock; + /* These are only updated and read within rto_lock */ + int rto_loop; + int rto_cpu; + /* These atomics are updated outside of a lock */ + atomic_t rto_loop_next; + atomic_t rto_loop_start; +#endif /* * The "RT overload" flag: it gets set if a CPU has more than * one runnable RT task. @@ -658,6 +665,9 @@ extern void init_defrootdomain(void); extern int sched_init_domains(const struct cpumask *cpu_map); extern void rq_attach_root(struct rq *rq, struct root_domain *rd); +#ifdef HAVE_RT_PUSH_IPI +extern void rto_push_irq_work_func(struct irq_work *work); +#endif #endif /* CONFIG_SMP */ /* diff --git a/kernel/sched/topology.c b/kernel/sched/topology.c index f51d123f9fe1..e50450c2fed8 100644 --- a/kernel/sched/topology.c +++ b/kernel/sched/topology.c @@ -268,6 +268,12 @@ static int init_rootdomain(struct root_domain *rd) if (!zalloc_cpumask_var(&rd->rto_mask, GFP_KERNEL)) goto free_dlo_mask; +#ifdef HAVE_RT_PUSH_IPI + rd->rto_cpu = -1; + raw_spin_lock_init(&rd->rto_lock); + init_irq_work(&rd->rto_push_work, rto_push_irq_work_func); +#endif + init_dl_bw(&rd->dl_bw); if (cpudl_init(&rd->cpudl) != 0) goto free_rto_mask;

7 years, 5 months

2
1
0 0

[Linux-stable-mirror] [PATCH v2] sunxi-rsb: Include OF based modalias in device uevent

by Stefan Brüns

Include the OF-based modalias in the uevent sent when registering devices on the sunxi RSB bus, so that user space has a chance to autoload the kernel module for the device. Fixes a regression caused by commit 3f241bfa60bd ("arm64: allwinner: a64: pine64: Use dcdc1 regulator for mmc0"). When the axp20x-rsb module for the AXP803 PMIC is built as a module, it is not loaded and the system ends up with an disfunctional MMC controller. Cc: stable <stable(a)vger.kernel.org> Signed-off-by: Stefan Brüns <stefan.bruens(a)rwth-aachen.de> --- drivers/bus/sunxi-rsb.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/bus/sunxi-rsb.c b/drivers/bus/sunxi-rsb.c index 328ca93781cf..1b76d9585902 100644 --- a/drivers/bus/sunxi-rsb.c +++ b/drivers/bus/sunxi-rsb.c @@ -178,6 +178,7 @@ static struct bus_type sunxi_rsb_bus = { .match = sunxi_rsb_device_match, .probe = sunxi_rsb_device_probe, .remove = sunxi_rsb_device_remove, + .uevent = of_device_uevent_modalias, }; static void sunxi_rsb_dev_release(struct device *dev) -- 2.15.0

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Applied "spi: a3700: Fix clk prescaling for coefficient over 15" to the spi tree

by Mark Brown

The patch spi: a3700: Fix clk prescaling for coefficient over 15 has been applied to the spi tree at https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark >From 251c201bf4f8b5bf4f1ccb4f8920eed2e1f57580 Mon Sep 17 00:00:00 2001 From: Maxime Chevallier <maxime.chevallier(a)smile.fr> Date: Mon, 27 Nov 2017 15:16:32 +0100 Subject: [PATCH] spi: a3700: Fix clk prescaling for coefficient over 15 The Armada 3700 SPI controller has 2 ranges of prescaler coefficients. One ranging from 0 to 15 by steps of 1, and one ranging from 0 to 30 by steps of 2. This commit fixes the prescaler coefficients that are over 15 so that it uses the correct range of values. The prescaling coefficient is rounded to the upper value if it is odd. This was tested on Espressobin with spidev and a locigal analyser. Signed-off-by: Maxime Chevallier <maxime.chevallier(a)smile.fr> Signed-off-by: Mark Brown <broonie(a)kernel.org> Cc: stable(a)vger.kernel.org --- drivers/spi/spi-armada-3700.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/drivers/spi/spi-armada-3700.c b/drivers/spi/spi-armada-3700.c index 77fe55ce790c..d65345312527 100644 --- a/drivers/spi/spi-armada-3700.c +++ b/drivers/spi/spi-armada-3700.c @@ -79,6 +79,7 @@ #define A3700_SPI_BYTE_LEN BIT(5) #define A3700_SPI_CLK_PRESCALE BIT(0) #define A3700_SPI_CLK_PRESCALE_MASK (0x1f) +#define A3700_SPI_CLK_EVEN_OFFS (0x10) #define A3700_SPI_WFIFO_THRS_BIT 28 #define A3700_SPI_RFIFO_THRS_BIT 24 @@ -220,6 +221,13 @@ static void a3700_spi_clock_set(struct a3700_spi *a3700_spi, prescale = DIV_ROUND_UP(clk_get_rate(a3700_spi->clk), speed_hz); + /* For prescaler values over 15, we can only set it by steps of 2. + * Starting from A3700_SPI_CLK_EVEN_OFFS, we set values from 0 up to + * 30. We only use this range from 16 to 30. + */ + if (prescale > 15) + prescale = A3700_SPI_CLK_EVEN_OFFS + DIV_ROUND_UP(prescale, 2); + val = spireg_read(a3700_spi, A3700_SPI_IF_CFG_REG); val = val & ~A3700_SPI_CLK_PRESCALE_MASK; -- 2.15.0

7 years, 5 months

1
0
0 0

Re: [Linux-stable-mirror] [PATCH] sunxi-rsb: Include OF based modalias in device uevent

by Chen-Yu Tsai

On Tue, Nov 28, 2017 at 1:19 AM, Stefan Brüns <stefan.bruens(a)rwth-aachen.de> wrote: > On Monday, November 27, 2017 4:35:02 PM CET Maxime Ripard wrote: >> Hi, >> >> On Mon, Nov 27, 2017 at 01:17:25PM +0100, Stefan Brüns wrote: >> > Include the OF-based modalias in the uevent sent when registering devices >> > on the sunxi RSB bus, so that user space has a chance to autoload the >> > kernel module for the device. >> > >> > Fixes a regression caused by commit 3f241bfa60bd ("arm64: allwinner: a64: >> > pine64: Use dcdc1 regulator for mmc0"). When the axp20x-rsb module for >> > the AXP803 PMIC is built as a module, it is not loaded and the system >> > ends up with an disfunctional MMC controller. >> > >> > Cc: stable <stable(a)vger.kernel.org> >> > Signed-off-by: Stefan Brüns <stefan.bruens(a)rwth-aachen.de> >> > --- >> > >> > drivers/bus/sunxi-rsb.c | 13 +++++++++++++ >> > 1 file changed, 13 insertions(+) >> > >> > diff --git a/drivers/bus/sunxi-rsb.c b/drivers/bus/sunxi-rsb.c >> > index 328ca93781cf..37cb57244cbe 100644 >> > --- a/drivers/bus/sunxi-rsb.c >> > +++ b/drivers/bus/sunxi-rsb.c >> > @@ -173,11 +173,24 @@ static int sunxi_rsb_device_remove(struct device >> > *dev)> >> > return drv->remove(to_sunxi_rsb_device(dev)); >> > >> > } >> > >> > +static int sunxi_rsb_device_uevent(struct device *dev, >> > + struct kobj_uevent_env *env) >> > +{ >> > + int ret; >> > + >> > + ret = of_device_uevent_modalias(dev, env); >> > + if (ret != -ENODEV) >> > + return ret; >> >> A comment explaining why we need to ignore the ENODEV error code would >> be great here. > > Lazy answer - everyone else is doing the same, and nobody cared to add an > explanation. > > For *some* drivers, this is likely because the same device may be enumerated > from e.g ACPI or OF, and for an ACPI device -ENODEV will be returned, as > dev->of_node is NULL. > > For devices which are only usable in an OF context, this is bogus. Not sure > about sunxi-rsb. sunxi-rsb (and Allwinner support in mainline in general) is OF only. With the exception of mfd sub-devices, if someone is enumerating devices in some other fashion, it should rightly blow up in their face. >> > + return 0; >> > +} >> > + >> > >> > static struct bus_type sunxi_rsb_bus = { >> > >> > .name = RSB_CTRL_NAME, >> > .match = sunxi_rsb_device_match, >> > .probe = sunxi_rsb_device_probe, >> > .remove = sunxi_rsb_device_remove, >> > >> > + .uevent = sunxi_rsb_device_uevent, >> >> Any reason to not use of_device_uevent_modalias directly here? > > *If* sunxi-rsb can be used without OF, then yes, otherwise no. You can just use of_device_uevent_modalias, like the other OF platforms. ChenYu

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "powerpc/signal: Properly handle return value from uprobe_deny_signal()" 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/signal: Properly handle return value from uprobe_deny_signal() 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-signal-properly-handle-return-value-from-uprobe_deny_signal.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 46725b17f1c6c815a41429259b3f070c01e71bc1 Mon Sep 17 00:00:00 2001 From: "Naveen N. Rao" <naveen.n.rao(a)linux.vnet.ibm.com> Date: Thu, 31 Aug 2017 21:55:57 +0530 Subject: powerpc/signal: Properly handle return value from uprobe_deny_signal() From: Naveen N. Rao <naveen.n.rao(a)linux.vnet.ibm.com> commit 46725b17f1c6c815a41429259b3f070c01e71bc1 upstream. When a uprobe is installed on an instruction that we currently do not emulate, we copy the instruction into a xol buffer and single step that instruction. If that instruction generates a fault, we abort the single stepping before invoking the signal handler. Once the signal handler is done, the uprobe trap is hit again since the instruction is retried and the process repeats. We use uprobe_deny_signal() to detect if the xol instruction triggered a signal. If so, we clear TIF_SIGPENDING and set TIF_UPROBE so that the signal is not handled until after the single stepping is aborted. In this case, uprobe_deny_signal() returns true and get_signal() ends up returning 0. However, in do_signal(), we are not looking at the return value, but depending on ksig.sig for further action, all with an uninitialized ksig that is not touched in this scenario. Fix the same by initializing ksig.sig to 0. Fixes: 129b69df9c90 ("powerpc: Use get_signal() signal_setup_done()") Reported-by: Anton Blanchard <anton(a)samba.org> Signed-off-by: Naveen N. Rao <naveen.n.rao(a)linux.vnet.ibm.com> Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/powerpc/kernel/signal.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/powerpc/kernel/signal.c +++ b/arch/powerpc/kernel/signal.c @@ -102,7 +102,7 @@ static void check_syscall_restart(struct static void do_signal(struct task_struct *tsk) { sigset_t *oldset = sigmask_to_save(); - struct ksignal ksig; + struct ksignal ksig = { .sig = 0 }; int ret; int is32 = is_32bit_task(); Patches currently in stable-queue which might be from naveen.n.rao(a)linux.vnet.ibm.com are queue-4.9/powerpc-signal-properly-handle-return-value-from-uprobe_deny_signal.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "parisc: Fix validity check of pointer size argument in new CAS implementation" 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 parisc: Fix validity check of pointer size argument in new CAS implementation 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: parisc-fix-validity-check-of-pointer-size-argument-in-new-cas-implementation.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 05f016d2ca7a4fab99d5d5472168506ddf95e74f Mon Sep 17 00:00:00 2001 From: John David Anglin <dave.anglin(a)bell.net> Date: Sat, 11 Nov 2017 17:11:16 -0500 Subject: parisc: Fix validity check of pointer size argument in new CAS implementation From: John David Anglin <dave.anglin(a)bell.net> commit 05f016d2ca7a4fab99d5d5472168506ddf95e74f upstream. As noted by Christoph Biedl, passing a pointer size of 4 in the new CAS implementation causes a kernel crash. The attached patch corrects the off by one error in the argument validity check. In reviewing the code, I noticed that we only perform word operations with the pointer size argument. The subi instruction intentionally uses a word condition on 64-bit kernels. Nullification was used instead of a cmpib instruction as the branch should never be taken. The shlw pseudo-operation generates a depw,z instruction and it clears the target before doing a shift left word deposit. Thus, we don't need to clip the upper 32 bits of this argument on 64-bit kernels. Tested with a gcc testsuite run with a 64-bit kernel. The gcc atomic code in libgcc is the only direct user of the new CAS implementation that I am aware of. Signed-off-by: John David Anglin <dave.anglin(a)bell.net> Signed-off-by: Helge Deller <deller(a)gmx.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/parisc/kernel/syscall.S | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) --- a/arch/parisc/kernel/syscall.S +++ b/arch/parisc/kernel/syscall.S @@ -690,15 +690,15 @@ cas_action: /* ELF32 Process entry path */ lws_compare_and_swap_2: #ifdef CONFIG_64BIT - /* Clip the input registers */ + /* Clip the input registers. We don't need to clip %r23 as we + only use it for word operations */ depdi 0, 31, 32, %r26 depdi 0, 31, 32, %r25 depdi 0, 31, 32, %r24 - depdi 0, 31, 32, %r23 #endif /* Check the validity of the size pointer */ - subi,>>= 4, %r23, %r0 + subi,>>= 3, %r23, %r0 b,n lws_exit_nosys /* Jump to the functions which will load the old and new values into Patches currently in stable-queue which might be from dave.anglin(a)bell.net are queue-4.9/parisc-fix-validity-check-of-pointer-size-argument-in-new-cas-implementation.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "media: v4l2-ctrl: Fix flags field on Control events" 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 media: v4l2-ctrl: Fix flags field on Control events 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: media-v4l2-ctrl-fix-flags-field-on-control-events.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 9cac9d2fb2fe0e0cadacdb94415b3fe49e3f724f Mon Sep 17 00:00:00 2001 From: Ricardo Ribalda <ricardo.ribalda(a)gmail.com> Date: Tue, 17 Oct 2017 11:48:50 -0400 Subject: media: v4l2-ctrl: Fix flags field on Control events From: Ricardo Ribalda Delgado <ricardo.ribalda(a)gmail.com> commit 9cac9d2fb2fe0e0cadacdb94415b3fe49e3f724f upstream. VIDIOC_DQEVENT and VIDIOC_QUERY_EXT_CTRL should give the same output for the control flags field. This patch creates a new function user_flags(), that calculates the user exported flags value (which is different than the kernel internal flags structure). This function is then used by all the code that exports the internal flags to userspace. Reported-by: Dimitrios Katsaros <patcherwork(a)gmail.com> Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda(a)gmail.com> Signed-off-by: Hans Verkuil <hans.verkuil(a)cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/media/v4l2-core/v4l2-ctrls.c | 16 ++++++++++++---- 1 file changed, 12 insertions(+), 4 deletions(-) --- a/drivers/media/v4l2-core/v4l2-ctrls.c +++ b/drivers/media/v4l2-core/v4l2-ctrls.c @@ -1219,6 +1219,16 @@ void v4l2_ctrl_fill(u32 id, const char * } EXPORT_SYMBOL(v4l2_ctrl_fill); +static u32 user_flags(const struct v4l2_ctrl *ctrl) +{ + u32 flags = ctrl->flags; + + if (ctrl->is_ptr) + flags |= V4L2_CTRL_FLAG_HAS_PAYLOAD; + + return flags; +} + static void fill_event(struct v4l2_event *ev, struct v4l2_ctrl *ctrl, u32 changes) { memset(ev->reserved, 0, sizeof(ev->reserved)); @@ -1226,7 +1236,7 @@ static void fill_event(struct v4l2_event ev->id = ctrl->id; ev->u.ctrl.changes = changes; ev->u.ctrl.type = ctrl->type; - ev->u.ctrl.flags = ctrl->flags; + ev->u.ctrl.flags = user_flags(ctrl); if (ctrl->is_ptr) ev->u.ctrl.value64 = 0; else @@ -2550,10 +2560,8 @@ int v4l2_query_ext_ctrl(struct v4l2_ctrl else qc->id = ctrl->id; strlcpy(qc->name, ctrl->name, sizeof(qc->name)); - qc->flags = ctrl->flags; + qc->flags = user_flags(ctrl); qc->type = ctrl->type; - if (ctrl->is_ptr) - qc->flags |= V4L2_CTRL_FLAG_HAS_PAYLOAD; qc->elem_size = ctrl->elem_size; qc->elems = ctrl->elems; qc->nr_of_dims = ctrl->nr_of_dims; Patches currently in stable-queue which might be from ricardo.ribalda(a)gmail.com are queue-4.9/media-v4l2-ctrl-fix-flags-field-on-control-events.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "media: rc: check for integer overflow" 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 media: rc: check for integer overflow 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: media-rc-check-for-integer-overflow.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 3e45067f94bbd61dec0619b1c32744eb0de480c8 Mon Sep 17 00:00:00 2001 From: Sean Young <sean(a)mess.org> Date: Sun, 8 Oct 2017 14:18:52 -0400 Subject: media: rc: check for integer overflow From: Sean Young <sean(a)mess.org> commit 3e45067f94bbd61dec0619b1c32744eb0de480c8 upstream. The ioctl LIRC_SET_REC_TIMEOUT would set a timeout of 704ns if called with a timeout of 4294968us. Signed-off-by: Sean Young <sean(a)mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/media/rc/ir-lirc-codec.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) --- a/drivers/media/rc/ir-lirc-codec.c +++ b/drivers/media/rc/ir-lirc-codec.c @@ -286,11 +286,14 @@ static long ir_lirc_ioctl(struct file *f if (!dev->max_timeout) return -ENOSYS; + /* Check for multiply overflow */ + if (val > U32_MAX / 1000) + return -EINVAL; + tmp = val * 1000; - if (tmp < dev->min_timeout || - tmp > dev->max_timeout) - return -EINVAL; + if (tmp < dev->min_timeout || tmp > dev->max_timeout) + return -EINVAL; if (dev->s_timeout) ret = dev->s_timeout(dev, tmp); Patches currently in stable-queue which might be from sean(a)mess.org are queue-4.9/media-rc-check-for-integer-overflow.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "media: Don't do DMA on stack for firmware upload in the AS102 driver" 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 media: Don't do DMA on stack for firmware upload in the AS102 driver 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: media-don-t-do-dma-on-stack-for-firmware-upload-in-the-as102-driver.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 b3120d2cc447ee77b9d69bf4ad7b452c9adb4d39 Mon Sep 17 00:00:00 2001 From: Michele Baldessari <michele(a)acksyn.org> Date: Mon, 6 Nov 2017 08:50:22 -0500 Subject: media: Don't do DMA on stack for firmware upload in the AS102 driver From: Michele Baldessari <michele(a)acksyn.org> commit b3120d2cc447ee77b9d69bf4ad7b452c9adb4d39 upstream. Firmware load on AS102 is using the stack which is not allowed any longer. We currently fail with: kernel: transfer buffer not dma capable kernel: ------------[ cut here ]------------ kernel: WARNING: CPU: 0 PID: 598 at drivers/usb/core/hcd.c:1595 usb_hcd_map_urb_for_dma+0x41d/0x620 kernel: Modules linked in: amd64_edac_mod(-) edac_mce_amd as102_fe dvb_as102(+) kvm_amd kvm snd_hda_codec_realtek dvb_core snd_hda_codec_generic snd_hda_codec_hdmi snd_hda_intel snd_hda_codec irqbypass crct10dif_pclmul crc32_pclmul snd_hda_core snd_hwdep snd_seq ghash_clmulni_intel sp5100_tco fam15h_power wmi k10temp i2c_piix4 snd_seq_device snd_pcm snd_timer parport_pc parport tpm_infineon snd tpm_tis soundcore tpm_tis_core tpm shpchp acpi_cpufreq xfs libcrc32c amdgpu amdkfd amd_iommu_v2 radeon hid_logitech_hidpp i2c_algo_bit drm_kms_helper crc32c_intel ttm drm r8169 mii hid_logitech_dj kernel: CPU: 0 PID: 598 Comm: systemd-udevd Not tainted 4.13.10-200.fc26.x86_64 #1 kernel: Hardware name: ASUS All Series/AM1I-A, BIOS 0505 03/13/2014 kernel: task: ffff979933b24c80 task.stack: ffffaf83413a4000 kernel: RIP: 0010:usb_hcd_map_urb_for_dma+0x41d/0x620 systemd-fsck[659]: /dev/sda2: clean, 49/128016 files, 268609/512000 blocks kernel: RSP: 0018:ffffaf83413a7728 EFLAGS: 00010282 systemd-udevd[604]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable. kernel: RAX: 000000000000001f RBX: ffff979930bce780 RCX: 0000000000000000 kernel: RDX: 0000000000000000 RSI: ffff97993ec0e118 RDI: ffff97993ec0e118 kernel: RBP: ffffaf83413a7768 R08: 000000000000039a R09: 0000000000000000 kernel: R10: 0000000000000001 R11: 00000000ffffffff R12: 00000000fffffff5 kernel: R13: 0000000001400000 R14: 0000000000000001 R15: ffff979930806800 kernel: FS: 00007effaca5c8c0(0000) GS:ffff97993ec00000(0000) knlGS:0000000000000000 kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 kernel: CR2: 00007effa9fca962 CR3: 0000000233089000 CR4: 00000000000406f0 kernel: Call Trace: kernel: usb_hcd_submit_urb+0x493/0xb40 kernel: ? page_cache_tree_insert+0x100/0x100 kernel: ? xfs_iunlock+0xd5/0x100 [xfs] kernel: ? xfs_file_buffered_aio_read+0x57/0xc0 [xfs] kernel: usb_submit_urb+0x22d/0x560 kernel: usb_start_wait_urb+0x6e/0x180 kernel: usb_bulk_msg+0xb8/0x160 kernel: as102_send_ep1+0x49/0xe0 [dvb_as102] kernel: ? devres_add+0x3f/0x50 kernel: as102_firmware_upload.isra.0+0x1dc/0x210 [dvb_as102] kernel: as102_fw_upload+0xb6/0x1f0 [dvb_as102] kernel: as102_dvb_register+0x2af/0x2d0 [dvb_as102] kernel: as102_usb_probe+0x1f3/0x260 [dvb_as102] kernel: usb_probe_interface+0x124/0x300 kernel: driver_probe_device+0x2ff/0x450 kernel: __driver_attach+0xa4/0xe0 kernel: ? driver_probe_device+0x450/0x450 kernel: bus_for_each_dev+0x6e/0xb0 kernel: driver_attach+0x1e/0x20 kernel: bus_add_driver+0x1c7/0x270 kernel: driver_register+0x60/0xe0 kernel: usb_register_driver+0x81/0x150 kernel: ? 0xffffffffc0807000 kernel: as102_usb_driver_init+0x1e/0x1000 [dvb_as102] kernel: do_one_initcall+0x50/0x190 kernel: ? __vunmap+0x81/0xb0 kernel: ? kfree+0x154/0x170 kernel: ? kmem_cache_alloc_trace+0x15f/0x1c0 kernel: ? do_init_module+0x27/0x1e9 kernel: do_init_module+0x5f/0x1e9 kernel: load_module+0x2602/0x2c30 kernel: SYSC_init_module+0x170/0x1a0 kernel: ? SYSC_init_module+0x170/0x1a0 kernel: SyS_init_module+0xe/0x10 kernel: do_syscall_64+0x67/0x140 kernel: entry_SYSCALL64_slow_path+0x25/0x25 kernel: RIP: 0033:0x7effab6cf3ea kernel: RSP: 002b:00007fff5cfcbbc8 EFLAGS: 00000246 ORIG_RAX: 00000000000000af kernel: RAX: ffffffffffffffda RBX: 00005569e0b83760 RCX: 00007effab6cf3ea kernel: RDX: 00007effac2099c5 RSI: 0000000000009a13 RDI: 00005569e0b98c50 kernel: RBP: 00007effac2099c5 R08: 00005569e0b83ed0 R09: 0000000000001d80 kernel: R10: 00007effab98db00 R11: 0000000000000246 R12: 00005569e0b98c50 kernel: R13: 00005569e0b81c60 R14: 0000000000020000 R15: 00005569dfadfdf7 kernel: Code: 48 39 c8 73 30 80 3d 59 60 9d 00 00 41 bc f5 ff ff ff 0f 85 26 ff ff ff 48 c7 c7 b8 6b d0 92 c6 05 3f 60 9d 00 01 e8 24 3d ad ff <0f> ff 8b 53 64 e9 09 ff ff ff 65 48 8b 0c 25 00 d3 00 00 48 8b kernel: ---[ end trace c4cae366180e70ec ]--- kernel: as10x_usb: error during firmware upload part1 Let's allocate the the structure dynamically so we can get the firmware loaded correctly: [ 14.243057] as10x_usb: firmware: as102_data1_st.hex loaded with success [ 14.500777] as10x_usb: firmware: as102_data2_st.hex loaded with success Signed-off-by: Michele Baldessari <michele(a)acksyn.org> Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/media/usb/as102/as102_fw.c | 28 +++++++++++++++++----------- 1 file changed, 17 insertions(+), 11 deletions(-) --- a/drivers/media/usb/as102/as102_fw.c +++ b/drivers/media/usb/as102/as102_fw.c @@ -101,18 +101,23 @@ static int as102_firmware_upload(struct unsigned char *cmd, const struct firmware *firmware) { - struct as10x_fw_pkt_t fw_pkt; + struct as10x_fw_pkt_t *fw_pkt; int total_read_bytes = 0, errno = 0; unsigned char addr_has_changed = 0; + fw_pkt = kmalloc(sizeof(*fw_pkt), GFP_KERNEL); + if (!fw_pkt) + return -ENOMEM; + + for (total_read_bytes = 0; total_read_bytes < firmware->size; ) { int read_bytes = 0, data_len = 0; /* parse intel hex line */ read_bytes = parse_hex_line( (u8 *) (firmware->data + total_read_bytes), - fw_pkt.raw.address, - fw_pkt.raw.data, + fw_pkt->raw.address, + fw_pkt->raw.data, &data_len, &addr_has_changed); @@ -122,28 +127,28 @@ static int as102_firmware_upload(struct /* detect the end of file */ total_read_bytes += read_bytes; if (total_read_bytes == firmware->size) { - fw_pkt.u.request[0] = 0x00; - fw_pkt.u.request[1] = 0x03; + fw_pkt->u.request[0] = 0x00; + fw_pkt->u.request[1] = 0x03; /* send EOF command */ errno = bus_adap->ops->upload_fw_pkt(bus_adap, (uint8_t *) - &fw_pkt, 2, 0); + fw_pkt, 2, 0); if (errno < 0) goto error; } else { if (!addr_has_changed) { /* prepare command to send */ - fw_pkt.u.request[0] = 0x00; - fw_pkt.u.request[1] = 0x01; + fw_pkt->u.request[0] = 0x00; + fw_pkt->u.request[1] = 0x01; - data_len += sizeof(fw_pkt.u.request); - data_len += sizeof(fw_pkt.raw.address); + data_len += sizeof(fw_pkt->u.request); + data_len += sizeof(fw_pkt->raw.address); /* send cmd to device */ errno = bus_adap->ops->upload_fw_pkt(bus_adap, (uint8_t *) - &fw_pkt, + fw_pkt, data_len, 0); if (errno < 0) @@ -152,6 +157,7 @@ static int as102_firmware_upload(struct } } error: + kfree(fw_pkt); return (errno == 0) ? total_read_bytes : errno; } Patches currently in stable-queue which might be from michele(a)acksyn.org are queue-4.9/media-don-t-do-dma-on-stack-for-firmware-upload-in-the-as102-driver.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "ixgbe: Fix skb list corruption on Power systems" 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 ixgbe: Fix skb list corruption on Power systems 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: ixgbe-fix-skb-list-corruption-on-power-systems.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 0a9a17e3bb4564caf4bfe2a6783ae1287667d188 Mon Sep 17 00:00:00 2001 From: Brian King <brking(a)linux.vnet.ibm.com> Date: Fri, 17 Nov 2017 11:05:43 -0600 Subject: ixgbe: Fix skb list corruption on Power systems From: Brian King <brking(a)linux.vnet.ibm.com> commit 0a9a17e3bb4564caf4bfe2a6783ae1287667d188 upstream. This patch fixes an issue seen on Power systems with ixgbe which results in skb list corruption and an eventual kernel oops. The following is what was observed: CPU 1 CPU2 ============================ ============================ 1: ixgbe_xmit_frame_ring ixgbe_clean_tx_irq 2: first->skb = skb eop_desc = tx_buffer->next_to_watch 3: ixgbe_tx_map read_barrier_depends() 4: wmb check adapter written status bit 5: first->next_to_watch = tx_desc napi_consume_skb(tx_buffer->skb ..); 6: writel(i, tx_ring->tail); The read_barrier_depends is insufficient to ensure that tx_buffer->skb does not get loaded prior to tx_buffer->next_to_watch, which then results in loading a stale skb pointer. This patch replaces the read_barrier_depends with smp_rmb to ensure loads are ordered with respect to the load of tx_buffer->next_to_watch. Signed-off-by: Brian King <brking(a)linux.vnet.ibm.com> Acked-by: Jesse Brandeburg <jesse.brandeburg(a)intel.com> Tested-by: Andrew Bowers <andrewx.bowers(a)intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher(a)intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c @@ -1171,7 +1171,7 @@ static bool ixgbe_clean_tx_irq(struct ix break; /* prevent any other reads prior to eop_desc */ - read_barrier_depends(); + smp_rmb(); /* if DD is not set pending work has not been completed */ if (!(eop_desc->wb.status & cpu_to_le32(IXGBE_TXD_STAT_DD))) Patches currently in stable-queue which might be from brking(a)linux.vnet.ibm.com are queue-4.9/i40evf-use-smp_rmb-rather-than-read_barrier_depends.patch queue-4.9/igb-use-smp_rmb-rather-than-read_barrier_depends.patch queue-4.9/ixgbevf-use-smp_rmb-rather-than-read_barrier_depends.patch queue-4.9/igbvf-use-smp_rmb-rather-than-read_barrier_depends.patch queue-4.9/fm10k-use-smp_rmb-rather-than-read_barrier_depends.patch queue-4.9/ixgbe-fix-skb-list-corruption-on-power-systems.patch queue-4.9/i40e-use-smp_rmb-rather-than-read_barrier_depends.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "ixgbevf: Use smp_rmb rather than read_barrier_depends" 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 ixgbevf: Use smp_rmb rather than read_barrier_depends 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: ixgbevf-use-smp_rmb-rather-than-read_barrier_depends.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 ae0c585d93dfaf923d2c7eb44b2c3ab92854ea9b Mon Sep 17 00:00:00 2001 From: Brian King <brking(a)linux.vnet.ibm.com> Date: Fri, 17 Nov 2017 11:05:45 -0600 Subject: ixgbevf: Use smp_rmb rather than read_barrier_depends From: Brian King <brking(a)linux.vnet.ibm.com> commit ae0c585d93dfaf923d2c7eb44b2c3ab92854ea9b upstream. The original issue being fixed in this patch was seen with the ixgbe driver, but the same issue exists with ixgbevf as well, as the code is very similar. read_barrier_depends is not sufficient to ensure loads following it are not speculatively loaded out of order by the CPU, which can result in stale data being loaded, causing potential system crashes. Signed-off-by: Brian King <brking(a)linux.vnet.ibm.com> Acked-by: Jesse Brandeburg <jesse.brandeburg(a)intel.com> Tested-by: Andrew Bowers <andrewx.bowers(a)intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher(a)intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c +++ b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c @@ -325,7 +325,7 @@ static bool ixgbevf_clean_tx_irq(struct break; /* prevent any other reads prior to eop_desc */ - read_barrier_depends(); + smp_rmb(); /* if DD is not set pending work has not been completed */ if (!(eop_desc->wb.status & cpu_to_le32(IXGBE_TXD_STAT_DD))) Patches currently in stable-queue which might be from brking(a)linux.vnet.ibm.com are queue-4.9/i40evf-use-smp_rmb-rather-than-read_barrier_depends.patch queue-4.9/igb-use-smp_rmb-rather-than-read_barrier_depends.patch queue-4.9/ixgbevf-use-smp_rmb-rather-than-read_barrier_depends.patch queue-4.9/igbvf-use-smp_rmb-rather-than-read_barrier_depends.patch queue-4.9/fm10k-use-smp_rmb-rather-than-read_barrier_depends.patch queue-4.9/ixgbe-fix-skb-list-corruption-on-power-systems.patch queue-4.9/i40e-use-smp_rmb-rather-than-read_barrier_depends.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "igbvf: Use smp_rmb rather than read_barrier_depends" 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 igbvf: Use smp_rmb rather than read_barrier_depends 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: igbvf-use-smp_rmb-rather-than-read_barrier_depends.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 1e1f9ca546556e508d021545861f6b5fc75a95fe Mon Sep 17 00:00:00 2001 From: Brian King <brking(a)linux.vnet.ibm.com> Date: Fri, 17 Nov 2017 11:05:46 -0600 Subject: igbvf: Use smp_rmb rather than read_barrier_depends From: Brian King <brking(a)linux.vnet.ibm.com> commit 1e1f9ca546556e508d021545861f6b5fc75a95fe upstream. The original issue being fixed in this patch was seen with the ixgbe driver, but the same issue exists with igbvf as well, as the code is very similar. read_barrier_depends is not sufficient to ensure loads following it are not speculatively loaded out of order by the CPU, which can result in stale data being loaded, causing potential system crashes. Signed-off-by: Brian King <brking(a)linux.vnet.ibm.com> Acked-by: Jesse Brandeburg <jesse.brandeburg(a)intel.com> Tested-by: Aaron Brown <aaron.f.brown(a)intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher(a)intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/intel/igbvf/netdev.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/net/ethernet/intel/igbvf/netdev.c +++ b/drivers/net/ethernet/intel/igbvf/netdev.c @@ -810,7 +810,7 @@ static bool igbvf_clean_tx_irq(struct ig break; /* prevent any other reads prior to eop_desc */ - read_barrier_depends(); + smp_rmb(); /* if DD is not set pending work has not been completed */ if (!(eop_desc->wb.status & cpu_to_le32(E1000_TXD_STAT_DD))) Patches currently in stable-queue which might be from brking(a)linux.vnet.ibm.com are queue-4.9/i40evf-use-smp_rmb-rather-than-read_barrier_depends.patch queue-4.9/igb-use-smp_rmb-rather-than-read_barrier_depends.patch queue-4.9/ixgbevf-use-smp_rmb-rather-than-read_barrier_depends.patch queue-4.9/igbvf-use-smp_rmb-rather-than-read_barrier_depends.patch queue-4.9/fm10k-use-smp_rmb-rather-than-read_barrier_depends.patch queue-4.9/ixgbe-fix-skb-list-corruption-on-power-systems.patch queue-4.9/i40e-use-smp_rmb-rather-than-read_barrier_depends.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "igb: Use smp_rmb rather than read_barrier_depends" 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 igb: Use smp_rmb rather than read_barrier_depends 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: igb-use-smp_rmb-rather-than-read_barrier_depends.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 c4cb99185b4cc96c0a1c70104dc21ae14d7e7f28 Mon Sep 17 00:00:00 2001 From: Brian King <brking(a)linux.vnet.ibm.com> Date: Fri, 17 Nov 2017 11:05:47 -0600 Subject: igb: Use smp_rmb rather than read_barrier_depends From: Brian King <brking(a)linux.vnet.ibm.com> commit c4cb99185b4cc96c0a1c70104dc21ae14d7e7f28 upstream. The original issue being fixed in this patch was seen with the ixgbe driver, but the same issue exists with igb as well, as the code is very similar. read_barrier_depends is not sufficient to ensure loads following it are not speculatively loaded out of order by the CPU, which can result in stale data being loaded, causing potential system crashes. Signed-off-by: Brian King <brking(a)linux.vnet.ibm.com> Acked-by: Jesse Brandeburg <jesse.brandeburg(a)intel.com> Tested-by: Aaron Brown <aaron.f.brown(a)intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher(a)intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/intel/igb/igb_main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/net/ethernet/intel/igb/igb_main.c +++ b/drivers/net/ethernet/intel/igb/igb_main.c @@ -6660,7 +6660,7 @@ static bool igb_clean_tx_irq(struct igb_ break; /* prevent any other reads prior to eop_desc */ - read_barrier_depends(); + smp_rmb(); /* if DD is not set pending work has not been completed */ if (!(eop_desc->wb.status & cpu_to_le32(E1000_TXD_STAT_DD))) Patches currently in stable-queue which might be from brking(a)linux.vnet.ibm.com are queue-4.9/i40evf-use-smp_rmb-rather-than-read_barrier_depends.patch queue-4.9/igb-use-smp_rmb-rather-than-read_barrier_depends.patch queue-4.9/ixgbevf-use-smp_rmb-rather-than-read_barrier_depends.patch queue-4.9/igbvf-use-smp_rmb-rather-than-read_barrier_depends.patch queue-4.9/fm10k-use-smp_rmb-rather-than-read_barrier_depends.patch queue-4.9/ixgbe-fix-skb-list-corruption-on-power-systems.patch queue-4.9/i40e-use-smp_rmb-rather-than-read_barrier_depends.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "i40evf: Use smp_rmb rather than read_barrier_depends" 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 i40evf: Use smp_rmb rather than read_barrier_depends 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: i40evf-use-smp_rmb-rather-than-read_barrier_depends.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 f72271e2a0ae4277d53c4053f5eed8bb346ba38a Mon Sep 17 00:00:00 2001 From: Brian King <brking(a)linux.vnet.ibm.com> Date: Fri, 17 Nov 2017 11:05:49 -0600 Subject: i40evf: Use smp_rmb rather than read_barrier_depends From: Brian King <brking(a)linux.vnet.ibm.com> commit f72271e2a0ae4277d53c4053f5eed8bb346ba38a upstream. The original issue being fixed in this patch was seen with the ixgbe driver, but the same issue exists with i40evf as well, as the code is very similar. read_barrier_depends is not sufficient to ensure loads following it are not speculatively loaded out of order by the CPU, which can result in stale data being loaded, causing potential system crashes. Signed-off-by: Brian King <brking(a)linux.vnet.ibm.com> Acked-by: Jesse Brandeburg <jesse.brandeburg(a)intel.com> Tested-by: Andrew Bowers <andrewx.bowers(a)intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher(a)intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/intel/i40evf/i40e_txrx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/net/ethernet/intel/i40evf/i40e_txrx.c +++ b/drivers/net/ethernet/intel/i40evf/i40e_txrx.c @@ -184,7 +184,7 @@ static bool i40e_clean_tx_irq(struct i40 break; /* prevent any other reads prior to eop_desc */ - read_barrier_depends(); + smp_rmb(); /* we have caught up to head, no work left to do */ if (tx_head == tx_desc) Patches currently in stable-queue which might be from brking(a)linux.vnet.ibm.com are queue-4.9/i40evf-use-smp_rmb-rather-than-read_barrier_depends.patch queue-4.9/igb-use-smp_rmb-rather-than-read_barrier_depends.patch queue-4.9/ixgbevf-use-smp_rmb-rather-than-read_barrier_depends.patch queue-4.9/igbvf-use-smp_rmb-rather-than-read_barrier_depends.patch queue-4.9/fm10k-use-smp_rmb-rather-than-read_barrier_depends.patch queue-4.9/ixgbe-fix-skb-list-corruption-on-power-systems.patch queue-4.9/i40e-use-smp_rmb-rather-than-read_barrier_depends.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "i40e: Use smp_rmb rather than read_barrier_depends" 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 i40e: Use smp_rmb rather than read_barrier_depends 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: i40e-use-smp_rmb-rather-than-read_barrier_depends.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 52c6912fde0133981ee50ba08808f257829c4c93 Mon Sep 17 00:00:00 2001 From: Brian King <brking(a)linux.vnet.ibm.com> Date: Fri, 17 Nov 2017 11:05:44 -0600 Subject: i40e: Use smp_rmb rather than read_barrier_depends From: Brian King <brking(a)linux.vnet.ibm.com> commit 52c6912fde0133981ee50ba08808f257829c4c93 upstream. The original issue being fixed in this patch was seen with the ixgbe driver, but the same issue exists with i40e as well, as the code is very similar. read_barrier_depends is not sufficient to ensure loads following it are not speculatively loaded out of order by the CPU, which can result in stale data being loaded, causing potential system crashes. Signed-off-by: Brian King <brking(a)linux.vnet.ibm.com> Acked-by: Jesse Brandeburg <jesse.brandeburg(a)intel.com> Tested-by: Andrew Bowers <andrewx.bowers(a)intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher(a)intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/intel/i40e/i40e_main.c | 2 +- drivers/net/ethernet/intel/i40e/i40e_txrx.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) --- a/drivers/net/ethernet/intel/i40e/i40e_main.c +++ b/drivers/net/ethernet/intel/i40e/i40e_main.c @@ -3604,7 +3604,7 @@ static bool i40e_clean_fdir_tx_irq(struc break; /* prevent any other reads prior to eop_desc */ - read_barrier_depends(); + smp_rmb(); /* if the descriptor isn't done, no work yet to do */ if (!(eop_desc->cmd_type_offset_bsz & --- a/drivers/net/ethernet/intel/i40e/i40e_txrx.c +++ b/drivers/net/ethernet/intel/i40e/i40e_txrx.c @@ -679,7 +679,7 @@ static bool i40e_clean_tx_irq(struct i40 break; /* prevent any other reads prior to eop_desc */ - read_barrier_depends(); + smp_rmb(); /* we have caught up to head, no work left to do */ if (tx_head == tx_desc) Patches currently in stable-queue which might be from brking(a)linux.vnet.ibm.com are queue-4.9/i40evf-use-smp_rmb-rather-than-read_barrier_depends.patch queue-4.9/igb-use-smp_rmb-rather-than-read_barrier_depends.patch queue-4.9/ixgbevf-use-smp_rmb-rather-than-read_barrier_depends.patch queue-4.9/igbvf-use-smp_rmb-rather-than-read_barrier_depends.patch queue-4.9/fm10k-use-smp_rmb-rather-than-read_barrier_depends.patch queue-4.9/ixgbe-fix-skb-list-corruption-on-power-systems.patch queue-4.9/i40e-use-smp_rmb-rather-than-read_barrier_depends.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "fm10k: Use smp_rmb rather than read_barrier_depends" 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 fm10k: Use smp_rmb rather than read_barrier_depends 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: fm10k-use-smp_rmb-rather-than-read_barrier_depends.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 7b8edcc685b5e2c3c37aa13dc50a88e84a5bfef8 Mon Sep 17 00:00:00 2001 From: Brian King <brking(a)linux.vnet.ibm.com> Date: Fri, 17 Nov 2017 11:05:48 -0600 Subject: fm10k: Use smp_rmb rather than read_barrier_depends From: Brian King <brking(a)linux.vnet.ibm.com> commit 7b8edcc685b5e2c3c37aa13dc50a88e84a5bfef8 upstream. The original issue being fixed in this patch was seen with the ixgbe driver, but the same issue exists with fm10k as well, as the code is very similar. read_barrier_depends is not sufficient to ensure loads following it are not speculatively loaded out of order by the CPU, which can result in stale data being loaded, causing potential system crashes. Signed-off-by: Brian King <brking(a)linux.vnet.ibm.com> Acked-by: Jesse Brandeburg <jesse.brandeburg(a)intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher(a)intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/intel/fm10k/fm10k_main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/net/ethernet/intel/fm10k/fm10k_main.c +++ b/drivers/net/ethernet/intel/fm10k/fm10k_main.c @@ -1225,7 +1225,7 @@ static bool fm10k_clean_tx_irq(struct fm break; /* prevent any other reads prior to eop_desc */ - read_barrier_depends(); + smp_rmb(); /* if DD is not set pending work has not been completed */ if (!(eop_desc->flags & FM10K_TXD_FLAG_DONE)) Patches currently in stable-queue which might be from brking(a)linux.vnet.ibm.com are queue-4.9/i40evf-use-smp_rmb-rather-than-read_barrier_depends.patch queue-4.9/igb-use-smp_rmb-rather-than-read_barrier_depends.patch queue-4.9/ixgbevf-use-smp_rmb-rather-than-read_barrier_depends.patch queue-4.9/igbvf-use-smp_rmb-rather-than-read_barrier_depends.patch queue-4.9/fm10k-use-smp_rmb-rather-than-read_barrier_depends.patch queue-4.9/ixgbe-fix-skb-list-corruption-on-power-systems.patch queue-4.9/i40e-use-smp_rmb-rather-than-read_barrier_depends.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "[media] cx231xx-cards: fix NULL-deref on missing association descriptor" 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 [media] cx231xx-cards: fix NULL-deref on missing association descriptor 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: cx231xx-cards-fix-null-deref-on-missing-association-descriptor.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 6c3b047fa2d2286d5e438bcb470c7b1a49f415f6 Mon Sep 17 00:00:00 2001 From: Johan Hovold <johan(a)kernel.org> Date: Thu, 21 Sep 2017 05:40:18 -0300 Subject: [media] cx231xx-cards: fix NULL-deref on missing association descriptor From: Johan Hovold <johan(a)kernel.org> commit 6c3b047fa2d2286d5e438bcb470c7b1a49f415f6 upstream. Make sure to check that we actually have an Interface Association Descriptor before dereferencing it during probe to avoid dereferencing a NULL-pointer. Fixes: e0d3bafd0258 ("V4L/DVB (10954): Add cx231xx USB driver") Reported-by: Andrey Konovalov <andreyknvl(a)google.com> Signed-off-by: Johan Hovold <johan(a)kernel.org> Tested-by: Andrey Konovalov <andreyknvl(a)google.com> Signed-off-by: Hans Verkuil <hans.verkuil(a)cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab(a)osg.samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/media/usb/cx231xx/cx231xx-cards.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/media/usb/cx231xx/cx231xx-cards.c +++ b/drivers/media/usb/cx231xx/cx231xx-cards.c @@ -1622,7 +1622,7 @@ static int cx231xx_usb_probe(struct usb_ nr = dev->devno; assoc_desc = udev->actconfig->intf_assoc[0]; - if (assoc_desc->bFirstInterface != ifnum) { + if (!assoc_desc || assoc_desc->bFirstInterface != ifnum) { dev_err(d, "Not found matching IAD interface\n"); retval = -ENODEV; goto err_if; Patches currently in stable-queue which might be from johan(a)kernel.org are queue-4.9/cx231xx-cards-fix-null-deref-on-missing-association-descriptor.patch queue-4.9/clk-ti-dra7-atl-clock-fix-child-node-lookups.patch queue-4.9/irqchip-gic-v3-fix-ppi-partitions-lookup.patch queue-4.9/nfc-fix-device-allocation-error-return.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "powerpc/signal: Properly handle return value from uprobe_deny_signal()" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled powerpc/signal: Properly handle return value from uprobe_deny_signal() to the 4.4-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-signal-properly-handle-return-value-from-uprobe_deny_signal.patch and it can be found in the queue-4.4 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 46725b17f1c6c815a41429259b3f070c01e71bc1 Mon Sep 17 00:00:00 2001 From: "Naveen N. Rao" <naveen.n.rao(a)linux.vnet.ibm.com> Date: Thu, 31 Aug 2017 21:55:57 +0530 Subject: powerpc/signal: Properly handle return value from uprobe_deny_signal() From: Naveen N. Rao <naveen.n.rao(a)linux.vnet.ibm.com> commit 46725b17f1c6c815a41429259b3f070c01e71bc1 upstream. When a uprobe is installed on an instruction that we currently do not emulate, we copy the instruction into a xol buffer and single step that instruction. If that instruction generates a fault, we abort the single stepping before invoking the signal handler. Once the signal handler is done, the uprobe trap is hit again since the instruction is retried and the process repeats. We use uprobe_deny_signal() to detect if the xol instruction triggered a signal. If so, we clear TIF_SIGPENDING and set TIF_UPROBE so that the signal is not handled until after the single stepping is aborted. In this case, uprobe_deny_signal() returns true and get_signal() ends up returning 0. However, in do_signal(), we are not looking at the return value, but depending on ksig.sig for further action, all with an uninitialized ksig that is not touched in this scenario. Fix the same by initializing ksig.sig to 0. Fixes: 129b69df9c90 ("powerpc: Use get_signal() signal_setup_done()") Reported-by: Anton Blanchard <anton(a)samba.org> Signed-off-by: Naveen N. Rao <naveen.n.rao(a)linux.vnet.ibm.com> Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/powerpc/kernel/signal.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/powerpc/kernel/signal.c +++ b/arch/powerpc/kernel/signal.c @@ -102,7 +102,7 @@ static void check_syscall_restart(struct static void do_signal(struct pt_regs *regs) { sigset_t *oldset = sigmask_to_save(); - struct ksignal ksig; + struct ksignal ksig = { .sig = 0 }; int ret; int is32 = is_32bit_task(); Patches currently in stable-queue which might be from naveen.n.rao(a)linux.vnet.ibm.com are queue-4.4/powerpc-signal-properly-handle-return-value-from-uprobe_deny_signal.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "parisc: Fix validity check of pointer size argument in new CAS implementation" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled parisc: Fix validity check of pointer size argument in new CAS implementation to the 4.4-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: parisc-fix-validity-check-of-pointer-size-argument-in-new-cas-implementation.patch and it can be found in the queue-4.4 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 05f016d2ca7a4fab99d5d5472168506ddf95e74f Mon Sep 17 00:00:00 2001 From: John David Anglin <dave.anglin(a)bell.net> Date: Sat, 11 Nov 2017 17:11:16 -0500 Subject: parisc: Fix validity check of pointer size argument in new CAS implementation From: John David Anglin <dave.anglin(a)bell.net> commit 05f016d2ca7a4fab99d5d5472168506ddf95e74f upstream. As noted by Christoph Biedl, passing a pointer size of 4 in the new CAS implementation causes a kernel crash. The attached patch corrects the off by one error in the argument validity check. In reviewing the code, I noticed that we only perform word operations with the pointer size argument. The subi instruction intentionally uses a word condition on 64-bit kernels. Nullification was used instead of a cmpib instruction as the branch should never be taken. The shlw pseudo-operation generates a depw,z instruction and it clears the target before doing a shift left word deposit. Thus, we don't need to clip the upper 32 bits of this argument on 64-bit kernels. Tested with a gcc testsuite run with a 64-bit kernel. The gcc atomic code in libgcc is the only direct user of the new CAS implementation that I am aware of. Signed-off-by: John David Anglin <dave.anglin(a)bell.net> Signed-off-by: Helge Deller <deller(a)gmx.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/parisc/kernel/syscall.S | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) --- a/arch/parisc/kernel/syscall.S +++ b/arch/parisc/kernel/syscall.S @@ -688,15 +688,15 @@ cas_action: /* ELF32 Process entry path */ lws_compare_and_swap_2: #ifdef CONFIG_64BIT - /* Clip the input registers */ + /* Clip the input registers. We don't need to clip %r23 as we + only use it for word operations */ depdi 0, 31, 32, %r26 depdi 0, 31, 32, %r25 depdi 0, 31, 32, %r24 - depdi 0, 31, 32, %r23 #endif /* Check the validity of the size pointer */ - subi,>>= 4, %r23, %r0 + subi,>>= 3, %r23, %r0 b,n lws_exit_nosys /* Jump to the functions which will load the old and new values into Patches currently in stable-queue which might be from dave.anglin(a)bell.net are queue-4.4/parisc-fix-validity-check-of-pointer-size-argument-in-new-cas-implementation.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "media: v4l2-ctrl: Fix flags field on Control events" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled media: v4l2-ctrl: Fix flags field on Control events to the 4.4-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: media-v4l2-ctrl-fix-flags-field-on-control-events.patch and it can be found in the queue-4.4 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 9cac9d2fb2fe0e0cadacdb94415b3fe49e3f724f Mon Sep 17 00:00:00 2001 From: Ricardo Ribalda <ricardo.ribalda(a)gmail.com> Date: Tue, 17 Oct 2017 11:48:50 -0400 Subject: media: v4l2-ctrl: Fix flags field on Control events From: Ricardo Ribalda Delgado <ricardo.ribalda(a)gmail.com> commit 9cac9d2fb2fe0e0cadacdb94415b3fe49e3f724f upstream. VIDIOC_DQEVENT and VIDIOC_QUERY_EXT_CTRL should give the same output for the control flags field. This patch creates a new function user_flags(), that calculates the user exported flags value (which is different than the kernel internal flags structure). This function is then used by all the code that exports the internal flags to userspace. Reported-by: Dimitrios Katsaros <patcherwork(a)gmail.com> Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda(a)gmail.com> Signed-off-by: Hans Verkuil <hans.verkuil(a)cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/media/v4l2-core/v4l2-ctrls.c | 16 ++++++++++++---- 1 file changed, 12 insertions(+), 4 deletions(-) --- a/drivers/media/v4l2-core/v4l2-ctrls.c +++ b/drivers/media/v4l2-core/v4l2-ctrls.c @@ -1200,6 +1200,16 @@ void v4l2_ctrl_fill(u32 id, const char * } EXPORT_SYMBOL(v4l2_ctrl_fill); +static u32 user_flags(const struct v4l2_ctrl *ctrl) +{ + u32 flags = ctrl->flags; + + if (ctrl->is_ptr) + flags |= V4L2_CTRL_FLAG_HAS_PAYLOAD; + + return flags; +} + static void fill_event(struct v4l2_event *ev, struct v4l2_ctrl *ctrl, u32 changes) { memset(ev->reserved, 0, sizeof(ev->reserved)); @@ -1207,7 +1217,7 @@ static void fill_event(struct v4l2_event ev->id = ctrl->id; ev->u.ctrl.changes = changes; ev->u.ctrl.type = ctrl->type; - ev->u.ctrl.flags = ctrl->flags; + ev->u.ctrl.flags = user_flags(ctrl); if (ctrl->is_ptr) ev->u.ctrl.value64 = 0; else @@ -2536,10 +2546,8 @@ int v4l2_query_ext_ctrl(struct v4l2_ctrl else qc->id = ctrl->id; strlcpy(qc->name, ctrl->name, sizeof(qc->name)); - qc->flags = ctrl->flags; + qc->flags = user_flags(ctrl); qc->type = ctrl->type; - if (ctrl->is_ptr) - qc->flags |= V4L2_CTRL_FLAG_HAS_PAYLOAD; qc->elem_size = ctrl->elem_size; qc->elems = ctrl->elems; qc->nr_of_dims = ctrl->nr_of_dims; Patches currently in stable-queue which might be from ricardo.ribalda(a)gmail.com are queue-4.4/media-v4l2-ctrl-fix-flags-field-on-control-events.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "media: rc: check for integer overflow" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled media: rc: check for integer overflow to the 4.4-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: media-rc-check-for-integer-overflow.patch and it can be found in the queue-4.4 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 3e45067f94bbd61dec0619b1c32744eb0de480c8 Mon Sep 17 00:00:00 2001 From: Sean Young <sean(a)mess.org> Date: Sun, 8 Oct 2017 14:18:52 -0400 Subject: media: rc: check for integer overflow From: Sean Young <sean(a)mess.org> commit 3e45067f94bbd61dec0619b1c32744eb0de480c8 upstream. The ioctl LIRC_SET_REC_TIMEOUT would set a timeout of 704ns if called with a timeout of 4294968us. Signed-off-by: Sean Young <sean(a)mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/media/rc/ir-lirc-codec.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) --- a/drivers/media/rc/ir-lirc-codec.c +++ b/drivers/media/rc/ir-lirc-codec.c @@ -286,11 +286,14 @@ static long ir_lirc_ioctl(struct file *f if (!dev->max_timeout) return -ENOSYS; + /* Check for multiply overflow */ + if (val > U32_MAX / 1000) + return -EINVAL; + tmp = val * 1000; - if (tmp < dev->min_timeout || - tmp > dev->max_timeout) - return -EINVAL; + if (tmp < dev->min_timeout || tmp > dev->max_timeout) + return -EINVAL; dev->timeout = tmp; break; Patches currently in stable-queue which might be from sean(a)mess.org are queue-4.4/media-rc-check-for-integer-overflow.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "media: Don't do DMA on stack for firmware upload in the AS102 driver" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled media: Don't do DMA on stack for firmware upload in the AS102 driver to the 4.4-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: media-don-t-do-dma-on-stack-for-firmware-upload-in-the-as102-driver.patch and it can be found in the queue-4.4 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 b3120d2cc447ee77b9d69bf4ad7b452c9adb4d39 Mon Sep 17 00:00:00 2001 From: Michele Baldessari <michele(a)acksyn.org> Date: Mon, 6 Nov 2017 08:50:22 -0500 Subject: media: Don't do DMA on stack for firmware upload in the AS102 driver From: Michele Baldessari <michele(a)acksyn.org> commit b3120d2cc447ee77b9d69bf4ad7b452c9adb4d39 upstream. Firmware load on AS102 is using the stack which is not allowed any longer. We currently fail with: kernel: transfer buffer not dma capable kernel: ------------[ cut here ]------------ kernel: WARNING: CPU: 0 PID: 598 at drivers/usb/core/hcd.c:1595 usb_hcd_map_urb_for_dma+0x41d/0x620 kernel: Modules linked in: amd64_edac_mod(-) edac_mce_amd as102_fe dvb_as102(+) kvm_amd kvm snd_hda_codec_realtek dvb_core snd_hda_codec_generic snd_hda_codec_hdmi snd_hda_intel snd_hda_codec irqbypass crct10dif_pclmul crc32_pclmul snd_hda_core snd_hwdep snd_seq ghash_clmulni_intel sp5100_tco fam15h_power wmi k10temp i2c_piix4 snd_seq_device snd_pcm snd_timer parport_pc parport tpm_infineon snd tpm_tis soundcore tpm_tis_core tpm shpchp acpi_cpufreq xfs libcrc32c amdgpu amdkfd amd_iommu_v2 radeon hid_logitech_hidpp i2c_algo_bit drm_kms_helper crc32c_intel ttm drm r8169 mii hid_logitech_dj kernel: CPU: 0 PID: 598 Comm: systemd-udevd Not tainted 4.13.10-200.fc26.x86_64 #1 kernel: Hardware name: ASUS All Series/AM1I-A, BIOS 0505 03/13/2014 kernel: task: ffff979933b24c80 task.stack: ffffaf83413a4000 kernel: RIP: 0010:usb_hcd_map_urb_for_dma+0x41d/0x620 systemd-fsck[659]: /dev/sda2: clean, 49/128016 files, 268609/512000 blocks kernel: RSP: 0018:ffffaf83413a7728 EFLAGS: 00010282 systemd-udevd[604]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable. kernel: RAX: 000000000000001f RBX: ffff979930bce780 RCX: 0000000000000000 kernel: RDX: 0000000000000000 RSI: ffff97993ec0e118 RDI: ffff97993ec0e118 kernel: RBP: ffffaf83413a7768 R08: 000000000000039a R09: 0000000000000000 kernel: R10: 0000000000000001 R11: 00000000ffffffff R12: 00000000fffffff5 kernel: R13: 0000000001400000 R14: 0000000000000001 R15: ffff979930806800 kernel: FS: 00007effaca5c8c0(0000) GS:ffff97993ec00000(0000) knlGS:0000000000000000 kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 kernel: CR2: 00007effa9fca962 CR3: 0000000233089000 CR4: 00000000000406f0 kernel: Call Trace: kernel: usb_hcd_submit_urb+0x493/0xb40 kernel: ? page_cache_tree_insert+0x100/0x100 kernel: ? xfs_iunlock+0xd5/0x100 [xfs] kernel: ? xfs_file_buffered_aio_read+0x57/0xc0 [xfs] kernel: usb_submit_urb+0x22d/0x560 kernel: usb_start_wait_urb+0x6e/0x180 kernel: usb_bulk_msg+0xb8/0x160 kernel: as102_send_ep1+0x49/0xe0 [dvb_as102] kernel: ? devres_add+0x3f/0x50 kernel: as102_firmware_upload.isra.0+0x1dc/0x210 [dvb_as102] kernel: as102_fw_upload+0xb6/0x1f0 [dvb_as102] kernel: as102_dvb_register+0x2af/0x2d0 [dvb_as102] kernel: as102_usb_probe+0x1f3/0x260 [dvb_as102] kernel: usb_probe_interface+0x124/0x300 kernel: driver_probe_device+0x2ff/0x450 kernel: __driver_attach+0xa4/0xe0 kernel: ? driver_probe_device+0x450/0x450 kernel: bus_for_each_dev+0x6e/0xb0 kernel: driver_attach+0x1e/0x20 kernel: bus_add_driver+0x1c7/0x270 kernel: driver_register+0x60/0xe0 kernel: usb_register_driver+0x81/0x150 kernel: ? 0xffffffffc0807000 kernel: as102_usb_driver_init+0x1e/0x1000 [dvb_as102] kernel: do_one_initcall+0x50/0x190 kernel: ? __vunmap+0x81/0xb0 kernel: ? kfree+0x154/0x170 kernel: ? kmem_cache_alloc_trace+0x15f/0x1c0 kernel: ? do_init_module+0x27/0x1e9 kernel: do_init_module+0x5f/0x1e9 kernel: load_module+0x2602/0x2c30 kernel: SYSC_init_module+0x170/0x1a0 kernel: ? SYSC_init_module+0x170/0x1a0 kernel: SyS_init_module+0xe/0x10 kernel: do_syscall_64+0x67/0x140 kernel: entry_SYSCALL64_slow_path+0x25/0x25 kernel: RIP: 0033:0x7effab6cf3ea kernel: RSP: 002b:00007fff5cfcbbc8 EFLAGS: 00000246 ORIG_RAX: 00000000000000af kernel: RAX: ffffffffffffffda RBX: 00005569e0b83760 RCX: 00007effab6cf3ea kernel: RDX: 00007effac2099c5 RSI: 0000000000009a13 RDI: 00005569e0b98c50 kernel: RBP: 00007effac2099c5 R08: 00005569e0b83ed0 R09: 0000000000001d80 kernel: R10: 00007effab98db00 R11: 0000000000000246 R12: 00005569e0b98c50 kernel: R13: 00005569e0b81c60 R14: 0000000000020000 R15: 00005569dfadfdf7 kernel: Code: 48 39 c8 73 30 80 3d 59 60 9d 00 00 41 bc f5 ff ff ff 0f 85 26 ff ff ff 48 c7 c7 b8 6b d0 92 c6 05 3f 60 9d 00 01 e8 24 3d ad ff <0f> ff 8b 53 64 e9 09 ff ff ff 65 48 8b 0c 25 00 d3 00 00 48 8b kernel: ---[ end trace c4cae366180e70ec ]--- kernel: as10x_usb: error during firmware upload part1 Let's allocate the the structure dynamically so we can get the firmware loaded correctly: [ 14.243057] as10x_usb: firmware: as102_data1_st.hex loaded with success [ 14.500777] as10x_usb: firmware: as102_data2_st.hex loaded with success Signed-off-by: Michele Baldessari <michele(a)acksyn.org> Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/media/usb/as102/as102_fw.c | 28 +++++++++++++++++----------- 1 file changed, 17 insertions(+), 11 deletions(-) --- a/drivers/media/usb/as102/as102_fw.c +++ b/drivers/media/usb/as102/as102_fw.c @@ -101,18 +101,23 @@ static int as102_firmware_upload(struct unsigned char *cmd, const struct firmware *firmware) { - struct as10x_fw_pkt_t fw_pkt; + struct as10x_fw_pkt_t *fw_pkt; int total_read_bytes = 0, errno = 0; unsigned char addr_has_changed = 0; + fw_pkt = kmalloc(sizeof(*fw_pkt), GFP_KERNEL); + if (!fw_pkt) + return -ENOMEM; + + for (total_read_bytes = 0; total_read_bytes < firmware->size; ) { int read_bytes = 0, data_len = 0; /* parse intel hex line */ read_bytes = parse_hex_line( (u8 *) (firmware->data + total_read_bytes), - fw_pkt.raw.address, - fw_pkt.raw.data, + fw_pkt->raw.address, + fw_pkt->raw.data, &data_len, &addr_has_changed); @@ -122,28 +127,28 @@ static int as102_firmware_upload(struct /* detect the end of file */ total_read_bytes += read_bytes; if (total_read_bytes == firmware->size) { - fw_pkt.u.request[0] = 0x00; - fw_pkt.u.request[1] = 0x03; + fw_pkt->u.request[0] = 0x00; + fw_pkt->u.request[1] = 0x03; /* send EOF command */ errno = bus_adap->ops->upload_fw_pkt(bus_adap, (uint8_t *) - &fw_pkt, 2, 0); + fw_pkt, 2, 0); if (errno < 0) goto error; } else { if (!addr_has_changed) { /* prepare command to send */ - fw_pkt.u.request[0] = 0x00; - fw_pkt.u.request[1] = 0x01; + fw_pkt->u.request[0] = 0x00; + fw_pkt->u.request[1] = 0x01; - data_len += sizeof(fw_pkt.u.request); - data_len += sizeof(fw_pkt.raw.address); + data_len += sizeof(fw_pkt->u.request); + data_len += sizeof(fw_pkt->raw.address); /* send cmd to device */ errno = bus_adap->ops->upload_fw_pkt(bus_adap, (uint8_t *) - &fw_pkt, + fw_pkt, data_len, 0); if (errno < 0) @@ -152,6 +157,7 @@ static int as102_firmware_upload(struct } } error: + kfree(fw_pkt); return (errno == 0) ? total_read_bytes : errno; } Patches currently in stable-queue which might be from michele(a)acksyn.org are queue-4.4/media-don-t-do-dma-on-stack-for-firmware-upload-in-the-as102-driver.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "ixgbevf: Use smp_rmb rather than read_barrier_depends" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ixgbevf: Use smp_rmb rather than read_barrier_depends to the 4.4-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: ixgbevf-use-smp_rmb-rather-than-read_barrier_depends.patch and it can be found in the queue-4.4 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 ae0c585d93dfaf923d2c7eb44b2c3ab92854ea9b Mon Sep 17 00:00:00 2001 From: Brian King <brking(a)linux.vnet.ibm.com> Date: Fri, 17 Nov 2017 11:05:45 -0600 Subject: ixgbevf: Use smp_rmb rather than read_barrier_depends From: Brian King <brking(a)linux.vnet.ibm.com> commit ae0c585d93dfaf923d2c7eb44b2c3ab92854ea9b upstream. The original issue being fixed in this patch was seen with the ixgbe driver, but the same issue exists with ixgbevf as well, as the code is very similar. read_barrier_depends is not sufficient to ensure loads following it are not speculatively loaded out of order by the CPU, which can result in stale data being loaded, causing potential system crashes. Signed-off-by: Brian King <brking(a)linux.vnet.ibm.com> Acked-by: Jesse Brandeburg <jesse.brandeburg(a)intel.com> Tested-by: Andrew Bowers <andrewx.bowers(a)intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher(a)intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c +++ b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c @@ -312,7 +312,7 @@ static bool ixgbevf_clean_tx_irq(struct break; /* prevent any other reads prior to eop_desc */ - read_barrier_depends(); + smp_rmb(); /* if DD is not set pending work has not been completed */ if (!(eop_desc->wb.status & cpu_to_le32(IXGBE_TXD_STAT_DD))) Patches currently in stable-queue which might be from brking(a)linux.vnet.ibm.com are queue-4.4/i40evf-use-smp_rmb-rather-than-read_barrier_depends.patch queue-4.4/igb-use-smp_rmb-rather-than-read_barrier_depends.patch queue-4.4/ixgbevf-use-smp_rmb-rather-than-read_barrier_depends.patch queue-4.4/igbvf-use-smp_rmb-rather-than-read_barrier_depends.patch queue-4.4/fm10k-use-smp_rmb-rather-than-read_barrier_depends.patch queue-4.4/ixgbe-fix-skb-list-corruption-on-power-systems.patch queue-4.4/i40e-use-smp_rmb-rather-than-read_barrier_depends.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "ixgbe: Fix skb list corruption on Power systems" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ixgbe: Fix skb list corruption on Power systems to the 4.4-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: ixgbe-fix-skb-list-corruption-on-power-systems.patch and it can be found in the queue-4.4 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 0a9a17e3bb4564caf4bfe2a6783ae1287667d188 Mon Sep 17 00:00:00 2001 From: Brian King <brking(a)linux.vnet.ibm.com> Date: Fri, 17 Nov 2017 11:05:43 -0600 Subject: ixgbe: Fix skb list corruption on Power systems From: Brian King <brking(a)linux.vnet.ibm.com> commit 0a9a17e3bb4564caf4bfe2a6783ae1287667d188 upstream. This patch fixes an issue seen on Power systems with ixgbe which results in skb list corruption and an eventual kernel oops. The following is what was observed: CPU 1 CPU2 ============================ ============================ 1: ixgbe_xmit_frame_ring ixgbe_clean_tx_irq 2: first->skb = skb eop_desc = tx_buffer->next_to_watch 3: ixgbe_tx_map read_barrier_depends() 4: wmb check adapter written status bit 5: first->next_to_watch = tx_desc napi_consume_skb(tx_buffer->skb ..); 6: writel(i, tx_ring->tail); The read_barrier_depends is insufficient to ensure that tx_buffer->skb does not get loaded prior to tx_buffer->next_to_watch, which then results in loading a stale skb pointer. This patch replaces the read_barrier_depends with smp_rmb to ensure loads are ordered with respect to the load of tx_buffer->next_to_watch. Signed-off-by: Brian King <brking(a)linux.vnet.ibm.com> Acked-by: Jesse Brandeburg <jesse.brandeburg(a)intel.com> Tested-by: Andrew Bowers <andrewx.bowers(a)intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher(a)intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c @@ -1114,7 +1114,7 @@ static bool ixgbe_clean_tx_irq(struct ix break; /* prevent any other reads prior to eop_desc */ - read_barrier_depends(); + smp_rmb(); /* if DD is not set pending work has not been completed */ if (!(eop_desc->wb.status & cpu_to_le32(IXGBE_TXD_STAT_DD))) Patches currently in stable-queue which might be from brking(a)linux.vnet.ibm.com are queue-4.4/i40evf-use-smp_rmb-rather-than-read_barrier_depends.patch queue-4.4/igb-use-smp_rmb-rather-than-read_barrier_depends.patch queue-4.4/ixgbevf-use-smp_rmb-rather-than-read_barrier_depends.patch queue-4.4/igbvf-use-smp_rmb-rather-than-read_barrier_depends.patch queue-4.4/fm10k-use-smp_rmb-rather-than-read_barrier_depends.patch queue-4.4/ixgbe-fix-skb-list-corruption-on-power-systems.patch queue-4.4/i40e-use-smp_rmb-rather-than-read_barrier_depends.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "igbvf: Use smp_rmb rather than read_barrier_depends" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled igbvf: Use smp_rmb rather than read_barrier_depends to the 4.4-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: igbvf-use-smp_rmb-rather-than-read_barrier_depends.patch and it can be found in the queue-4.4 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 1e1f9ca546556e508d021545861f6b5fc75a95fe Mon Sep 17 00:00:00 2001 From: Brian King <brking(a)linux.vnet.ibm.com> Date: Fri, 17 Nov 2017 11:05:46 -0600 Subject: igbvf: Use smp_rmb rather than read_barrier_depends From: Brian King <brking(a)linux.vnet.ibm.com> commit 1e1f9ca546556e508d021545861f6b5fc75a95fe upstream. The original issue being fixed in this patch was seen with the ixgbe driver, but the same issue exists with igbvf as well, as the code is very similar. read_barrier_depends is not sufficient to ensure loads following it are not speculatively loaded out of order by the CPU, which can result in stale data being loaded, causing potential system crashes. Signed-off-by: Brian King <brking(a)linux.vnet.ibm.com> Acked-by: Jesse Brandeburg <jesse.brandeburg(a)intel.com> Tested-by: Aaron Brown <aaron.f.brown(a)intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher(a)intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/intel/igbvf/netdev.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/net/ethernet/intel/igbvf/netdev.c +++ b/drivers/net/ethernet/intel/igbvf/netdev.c @@ -809,7 +809,7 @@ static bool igbvf_clean_tx_irq(struct ig break; /* prevent any other reads prior to eop_desc */ - read_barrier_depends(); + smp_rmb(); /* if DD is not set pending work has not been completed */ if (!(eop_desc->wb.status & cpu_to_le32(E1000_TXD_STAT_DD))) Patches currently in stable-queue which might be from brking(a)linux.vnet.ibm.com are queue-4.4/i40evf-use-smp_rmb-rather-than-read_barrier_depends.patch queue-4.4/igb-use-smp_rmb-rather-than-read_barrier_depends.patch queue-4.4/ixgbevf-use-smp_rmb-rather-than-read_barrier_depends.patch queue-4.4/igbvf-use-smp_rmb-rather-than-read_barrier_depends.patch queue-4.4/fm10k-use-smp_rmb-rather-than-read_barrier_depends.patch queue-4.4/ixgbe-fix-skb-list-corruption-on-power-systems.patch queue-4.4/i40e-use-smp_rmb-rather-than-read_barrier_depends.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "igb: Use smp_rmb rather than read_barrier_depends" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled igb: Use smp_rmb rather than read_barrier_depends to the 4.4-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: igb-use-smp_rmb-rather-than-read_barrier_depends.patch and it can be found in the queue-4.4 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 c4cb99185b4cc96c0a1c70104dc21ae14d7e7f28 Mon Sep 17 00:00:00 2001 From: Brian King <brking(a)linux.vnet.ibm.com> Date: Fri, 17 Nov 2017 11:05:47 -0600 Subject: igb: Use smp_rmb rather than read_barrier_depends From: Brian King <brking(a)linux.vnet.ibm.com> commit c4cb99185b4cc96c0a1c70104dc21ae14d7e7f28 upstream. The original issue being fixed in this patch was seen with the ixgbe driver, but the same issue exists with igb as well, as the code is very similar. read_barrier_depends is not sufficient to ensure loads following it are not speculatively loaded out of order by the CPU, which can result in stale data being loaded, causing potential system crashes. Signed-off-by: Brian King <brking(a)linux.vnet.ibm.com> Acked-by: Jesse Brandeburg <jesse.brandeburg(a)intel.com> Tested-by: Aaron Brown <aaron.f.brown(a)intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher(a)intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/intel/igb/igb_main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/net/ethernet/intel/igb/igb_main.c +++ b/drivers/net/ethernet/intel/igb/igb_main.c @@ -6433,7 +6433,7 @@ static bool igb_clean_tx_irq(struct igb_ break; /* prevent any other reads prior to eop_desc */ - read_barrier_depends(); + smp_rmb(); /* if DD is not set pending work has not been completed */ if (!(eop_desc->wb.status & cpu_to_le32(E1000_TXD_STAT_DD))) Patches currently in stable-queue which might be from brking(a)linux.vnet.ibm.com are queue-4.4/i40evf-use-smp_rmb-rather-than-read_barrier_depends.patch queue-4.4/igb-use-smp_rmb-rather-than-read_barrier_depends.patch queue-4.4/ixgbevf-use-smp_rmb-rather-than-read_barrier_depends.patch queue-4.4/igbvf-use-smp_rmb-rather-than-read_barrier_depends.patch queue-4.4/fm10k-use-smp_rmb-rather-than-read_barrier_depends.patch queue-4.4/ixgbe-fix-skb-list-corruption-on-power-systems.patch queue-4.4/i40e-use-smp_rmb-rather-than-read_barrier_depends.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "i40evf: Use smp_rmb rather than read_barrier_depends" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled i40evf: Use smp_rmb rather than read_barrier_depends to the 4.4-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: i40evf-use-smp_rmb-rather-than-read_barrier_depends.patch and it can be found in the queue-4.4 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 f72271e2a0ae4277d53c4053f5eed8bb346ba38a Mon Sep 17 00:00:00 2001 From: Brian King <brking(a)linux.vnet.ibm.com> Date: Fri, 17 Nov 2017 11:05:49 -0600 Subject: i40evf: Use smp_rmb rather than read_barrier_depends From: Brian King <brking(a)linux.vnet.ibm.com> commit f72271e2a0ae4277d53c4053f5eed8bb346ba38a upstream. The original issue being fixed in this patch was seen with the ixgbe driver, but the same issue exists with i40evf as well, as the code is very similar. read_barrier_depends is not sufficient to ensure loads following it are not speculatively loaded out of order by the CPU, which can result in stale data being loaded, causing potential system crashes. Signed-off-by: Brian King <brking(a)linux.vnet.ibm.com> Acked-by: Jesse Brandeburg <jesse.brandeburg(a)intel.com> Tested-by: Andrew Bowers <andrewx.bowers(a)intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher(a)intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/intel/i40evf/i40e_txrx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/net/ethernet/intel/i40evf/i40e_txrx.c +++ b/drivers/net/ethernet/intel/i40evf/i40e_txrx.c @@ -172,7 +172,7 @@ static bool i40e_clean_tx_irq(struct i40 break; /* prevent any other reads prior to eop_desc */ - read_barrier_depends(); + smp_rmb(); /* we have caught up to head, no work left to do */ if (tx_head == tx_desc) Patches currently in stable-queue which might be from brking(a)linux.vnet.ibm.com are queue-4.4/i40evf-use-smp_rmb-rather-than-read_barrier_depends.patch queue-4.4/igb-use-smp_rmb-rather-than-read_barrier_depends.patch queue-4.4/ixgbevf-use-smp_rmb-rather-than-read_barrier_depends.patch queue-4.4/igbvf-use-smp_rmb-rather-than-read_barrier_depends.patch queue-4.4/fm10k-use-smp_rmb-rather-than-read_barrier_depends.patch queue-4.4/ixgbe-fix-skb-list-corruption-on-power-systems.patch queue-4.4/i40e-use-smp_rmb-rather-than-read_barrier_depends.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "i40e: Use smp_rmb rather than read_barrier_depends" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled i40e: Use smp_rmb rather than read_barrier_depends to the 4.4-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: i40e-use-smp_rmb-rather-than-read_barrier_depends.patch and it can be found in the queue-4.4 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 52c6912fde0133981ee50ba08808f257829c4c93 Mon Sep 17 00:00:00 2001 From: Brian King <brking(a)linux.vnet.ibm.com> Date: Fri, 17 Nov 2017 11:05:44 -0600 Subject: i40e: Use smp_rmb rather than read_barrier_depends From: Brian King <brking(a)linux.vnet.ibm.com> commit 52c6912fde0133981ee50ba08808f257829c4c93 upstream. The original issue being fixed in this patch was seen with the ixgbe driver, but the same issue exists with i40e as well, as the code is very similar. read_barrier_depends is not sufficient to ensure loads following it are not speculatively loaded out of order by the CPU, which can result in stale data being loaded, causing potential system crashes. Signed-off-by: Brian King <brking(a)linux.vnet.ibm.com> Acked-by: Jesse Brandeburg <jesse.brandeburg(a)intel.com> Tested-by: Andrew Bowers <andrewx.bowers(a)intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher(a)intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/intel/i40e/i40e_main.c | 2 +- drivers/net/ethernet/intel/i40e/i40e_txrx.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) --- a/drivers/net/ethernet/intel/i40e/i40e_main.c +++ b/drivers/net/ethernet/intel/i40e/i40e_main.c @@ -3595,7 +3595,7 @@ static bool i40e_clean_fdir_tx_irq(struc break; /* prevent any other reads prior to eop_desc */ - read_barrier_depends(); + smp_rmb(); /* if the descriptor isn't done, no work yet to do */ if (!(eop_desc->cmd_type_offset_bsz & --- a/drivers/net/ethernet/intel/i40e/i40e_txrx.c +++ b/drivers/net/ethernet/intel/i40e/i40e_txrx.c @@ -663,7 +663,7 @@ static bool i40e_clean_tx_irq(struct i40 break; /* prevent any other reads prior to eop_desc */ - read_barrier_depends(); + smp_rmb(); /* we have caught up to head, no work left to do */ if (tx_head == tx_desc) Patches currently in stable-queue which might be from brking(a)linux.vnet.ibm.com are queue-4.4/i40evf-use-smp_rmb-rather-than-read_barrier_depends.patch queue-4.4/igb-use-smp_rmb-rather-than-read_barrier_depends.patch queue-4.4/ixgbevf-use-smp_rmb-rather-than-read_barrier_depends.patch queue-4.4/igbvf-use-smp_rmb-rather-than-read_barrier_depends.patch queue-4.4/fm10k-use-smp_rmb-rather-than-read_barrier_depends.patch queue-4.4/ixgbe-fix-skb-list-corruption-on-power-systems.patch queue-4.4/i40e-use-smp_rmb-rather-than-read_barrier_depends.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "fm10k: Use smp_rmb rather than read_barrier_depends" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled fm10k: Use smp_rmb rather than read_barrier_depends to the 4.4-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: fm10k-use-smp_rmb-rather-than-read_barrier_depends.patch and it can be found in the queue-4.4 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 7b8edcc685b5e2c3c37aa13dc50a88e84a5bfef8 Mon Sep 17 00:00:00 2001 From: Brian King <brking(a)linux.vnet.ibm.com> Date: Fri, 17 Nov 2017 11:05:48 -0600 Subject: fm10k: Use smp_rmb rather than read_barrier_depends From: Brian King <brking(a)linux.vnet.ibm.com> commit 7b8edcc685b5e2c3c37aa13dc50a88e84a5bfef8 upstream. The original issue being fixed in this patch was seen with the ixgbe driver, but the same issue exists with fm10k as well, as the code is very similar. read_barrier_depends is not sufficient to ensure loads following it are not speculatively loaded out of order by the CPU, which can result in stale data being loaded, causing potential system crashes. Signed-off-by: Brian King <brking(a)linux.vnet.ibm.com> Acked-by: Jesse Brandeburg <jesse.brandeburg(a)intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher(a)intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/intel/fm10k/fm10k_main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/net/ethernet/intel/fm10k/fm10k_main.c +++ b/drivers/net/ethernet/intel/fm10k/fm10k_main.c @@ -1226,7 +1226,7 @@ static bool fm10k_clean_tx_irq(struct fm break; /* prevent any other reads prior to eop_desc */ - read_barrier_depends(); + smp_rmb(); /* if DD is not set pending work has not been completed */ if (!(eop_desc->flags & FM10K_TXD_FLAG_DONE)) Patches currently in stable-queue which might be from brking(a)linux.vnet.ibm.com are queue-4.4/i40evf-use-smp_rmb-rather-than-read_barrier_depends.patch queue-4.4/igb-use-smp_rmb-rather-than-read_barrier_depends.patch queue-4.4/ixgbevf-use-smp_rmb-rather-than-read_barrier_depends.patch queue-4.4/igbvf-use-smp_rmb-rather-than-read_barrier_depends.patch queue-4.4/fm10k-use-smp_rmb-rather-than-read_barrier_depends.patch queue-4.4/ixgbe-fix-skb-list-corruption-on-power-systems.patch queue-4.4/i40e-use-smp_rmb-rather-than-read_barrier_depends.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "[media] cx231xx-cards: fix NULL-deref on missing association descriptor" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled [media] cx231xx-cards: fix NULL-deref on missing association descriptor to the 4.4-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: cx231xx-cards-fix-null-deref-on-missing-association-descriptor.patch and it can be found in the queue-4.4 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 6c3b047fa2d2286d5e438bcb470c7b1a49f415f6 Mon Sep 17 00:00:00 2001 From: Johan Hovold <johan(a)kernel.org> Date: Thu, 21 Sep 2017 05:40:18 -0300 Subject: [media] cx231xx-cards: fix NULL-deref on missing association descriptor From: Johan Hovold <johan(a)kernel.org> commit 6c3b047fa2d2286d5e438bcb470c7b1a49f415f6 upstream. Make sure to check that we actually have an Interface Association Descriptor before dereferencing it during probe to avoid dereferencing a NULL-pointer. Fixes: e0d3bafd0258 ("V4L/DVB (10954): Add cx231xx USB driver") Reported-by: Andrey Konovalov <andreyknvl(a)google.com> Signed-off-by: Johan Hovold <johan(a)kernel.org> Tested-by: Andrey Konovalov <andreyknvl(a)google.com> Signed-off-by: Hans Verkuil <hans.verkuil(a)cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab(a)osg.samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/media/usb/cx231xx/cx231xx-cards.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/media/usb/cx231xx/cx231xx-cards.c +++ b/drivers/media/usb/cx231xx/cx231xx-cards.c @@ -1672,7 +1672,7 @@ static int cx231xx_usb_probe(struct usb_ nr = dev->devno; assoc_desc = udev->actconfig->intf_assoc[0]; - if (assoc_desc->bFirstInterface != ifnum) { + if (!assoc_desc || assoc_desc->bFirstInterface != ifnum) { dev_err(d, "Not found matching IAD interface\n"); retval = -ENODEV; goto err_if; Patches currently in stable-queue which might be from johan(a)kernel.org are queue-4.4/cx231xx-cards-fix-null-deref-on-missing-association-descriptor.patch queue-4.4/clk-ti-dra7-atl-clock-fix-child-node-lookups.patch queue-4.4/nfc-fix-device-allocation-error-return.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "powerpc/signal: Properly handle return value from uprobe_deny_signal()" 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/signal: Properly handle return value from uprobe_deny_signal() 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-signal-properly-handle-return-value-from-uprobe_deny_signal.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 46725b17f1c6c815a41429259b3f070c01e71bc1 Mon Sep 17 00:00:00 2001 From: "Naveen N. Rao" <naveen.n.rao(a)linux.vnet.ibm.com> Date: Thu, 31 Aug 2017 21:55:57 +0530 Subject: powerpc/signal: Properly handle return value from uprobe_deny_signal() From: Naveen N. Rao <naveen.n.rao(a)linux.vnet.ibm.com> commit 46725b17f1c6c815a41429259b3f070c01e71bc1 upstream. When a uprobe is installed on an instruction that we currently do not emulate, we copy the instruction into a xol buffer and single step that instruction. If that instruction generates a fault, we abort the single stepping before invoking the signal handler. Once the signal handler is done, the uprobe trap is hit again since the instruction is retried and the process repeats. We use uprobe_deny_signal() to detect if the xol instruction triggered a signal. If so, we clear TIF_SIGPENDING and set TIF_UPROBE so that the signal is not handled until after the single stepping is aborted. In this case, uprobe_deny_signal() returns true and get_signal() ends up returning 0. However, in do_signal(), we are not looking at the return value, but depending on ksig.sig for further action, all with an uninitialized ksig that is not touched in this scenario. Fix the same by initializing ksig.sig to 0. Fixes: 129b69df9c90 ("powerpc: Use get_signal() signal_setup_done()") Reported-by: Anton Blanchard <anton(a)samba.org> Signed-off-by: Naveen N. Rao <naveen.n.rao(a)linux.vnet.ibm.com> Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/powerpc/kernel/signal.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/powerpc/kernel/signal.c +++ b/arch/powerpc/kernel/signal.c @@ -103,7 +103,7 @@ static void check_syscall_restart(struct static void do_signal(struct task_struct *tsk) { sigset_t *oldset = sigmask_to_save(); - struct ksignal ksig; + struct ksignal ksig = { .sig = 0 }; int ret; int is32 = is_32bit_task(); Patches currently in stable-queue which might be from naveen.n.rao(a)linux.vnet.ibm.com are queue-4.14/powerpc-signal-properly-handle-return-value-from-uprobe_deny_signal.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "powerpc/mm/radix: Fix crashes on Power9 DD1 with radix MMU and STRICT_RWX" 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/mm/radix: Fix crashes on Power9 DD1 with radix MMU and STRICT_RWX 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-mm-radix-fix-crashes-on-power9-dd1-with-radix-mmu-and-strict_rwx.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 f79ad50ea3c73fb1ea5b09e95c864e5bb263adfb Mon Sep 17 00:00:00 2001 From: Balbir Singh <bsingharora(a)gmail.com> Date: Mon, 16 Oct 2017 16:21:35 +1100 Subject: powerpc/mm/radix: Fix crashes on Power9 DD1 with radix MMU and STRICT_RWX From: Balbir Singh <bsingharora(a)gmail.com> commit f79ad50ea3c73fb1ea5b09e95c864e5bb263adfb upstream. When using the radix MMU on Power9 DD1, to work around a hardware problem, radix__pte_update() is required to do a two stage update of the PTE. First we write a zero value into the PTE, then we flush the TLB, and then we write the new PTE value. In the normal case that works OK, but it does not work if we're updating the PTE that maps the code we're executing, because the mapping is removed by the TLB flush and we can no longer execute from it. Unfortunately the STRICT_RWX code needs to do exactly that. The exact symptoms when we hit this case vary, sometimes we print an oops and then get stuck after that, but I've also seen a machine just get stuck continually page faulting with no oops printed. The variance is presumably due to the exact layout of the text and the page size used for the mappings. In all cases we are unable to boot to a shell. There are possible solutions such as creating a second mapping of the TLB flush code, executing from that, and then jumping back to the original. However we don't want to add that level of complexity for a DD1 work around. So just detect that we're running on Power9 DD1 and refrain from changing the permissions, effectively disabling STRICT_RWX on Power9 DD1. Fixes: 7614ff3272a1 ("powerpc/mm/radix: Implement STRICT_RWX/mark_rodata_ro() for Radix") Reported-by: Andrew Jeffery <andrew(a)aj.id.au> [Changelog as suggested by Michael Ellerman <mpe(a)ellerman.id.au>] Signed-off-by: Balbir Singh <bsingharora(a)gmail.com> Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/powerpc/mm/pgtable-radix.c | 10 ++++++++++ 1 file changed, 10 insertions(+) --- a/arch/powerpc/mm/pgtable-radix.c +++ b/arch/powerpc/mm/pgtable-radix.c @@ -169,6 +169,16 @@ void radix__mark_rodata_ro(void) { unsigned long start, end; + /* + * mark_rodata_ro() will mark itself as !writable at some point. + * Due to DD1 workaround in radix__pte_update(), we'll end up with + * an invalid pte and the system will crash quite severly. + */ + if (cpu_has_feature(CPU_FTR_POWER9_DD1)) { + pr_warn("Warning: Unable to mark rodata read only on P9 DD1\n"); + return; + } + start = (unsigned long)_stext; end = (unsigned long)__init_begin; Patches currently in stable-queue which might be from bsingharora(a)gmail.com are queue-4.14/powerpc-mm-radix-fix-crashes-on-power9-dd1-with-radix-mmu-and-strict_rwx.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "powerpc/perf/imc: Use cpu_to_node() not topology_physical_package_id()" 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/perf/imc: Use cpu_to_node() not topology_physical_package_id() 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-perf-imc-use-cpu_to_node-not-topology_physical_package_id.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 f3f1dfd600ff82b18b7ea73d80eb27f476a6aa97 Mon Sep 17 00:00:00 2001 From: Michael Ellerman <mpe(a)ellerman.id.au> Date: Mon, 16 Oct 2017 00:13:41 +0530 Subject: powerpc/perf/imc: Use cpu_to_node() not topology_physical_package_id() From: Michael Ellerman <mpe(a)ellerman.id.au> commit f3f1dfd600ff82b18b7ea73d80eb27f476a6aa97 upstream. init_imc_pmu() uses topology_physical_package_id() to detect the node id of the processor it is on to get local memory, but that's wrong, and can lead to crashes. Fix it to use cpu_to_node(). Fixes: 885dcd709ba9 ("powerpc/perf: Add nest IMC PMU support") Reported-By: Rob Lippert <rlippert(a)google.com> Tested-By: Madhavan Srinivasan <maddy(a)linux.vnet.ibm.com> Signed-off-by: Madhavan Srinivasan <maddy(a)linux.vnet.ibm.com> Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/powerpc/perf/imc-pmu.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) --- a/arch/powerpc/perf/imc-pmu.c +++ b/arch/powerpc/perf/imc-pmu.c @@ -467,7 +467,7 @@ static int nest_imc_event_init(struct pe * Nest HW counter memory resides in a per-chip reserve-memory (HOMER). * Get the base memory addresss for this cpu. */ - chip_id = topology_physical_package_id(event->cpu); + chip_id = cpu_to_chip_id(event->cpu); pcni = pmu->mem_info; do { if (pcni->id == chip_id) { @@ -524,19 +524,19 @@ static int nest_imc_event_init(struct pe */ static int core_imc_mem_init(int cpu, int size) { - int phys_id, rc = 0, core_id = (cpu / threads_per_core); + int nid, rc = 0, core_id = (cpu / threads_per_core); struct imc_mem_info *mem_info; /* * alloc_pages_node() will allocate memory for core in the * local node only. */ - phys_id = topology_physical_package_id(cpu); + nid = cpu_to_node(cpu); mem_info = &core_imc_pmu->mem_info[core_id]; mem_info->id = core_id; /* We need only vbase for core counters */ - mem_info->vbase = page_address(alloc_pages_node(phys_id, + mem_info->vbase = page_address(alloc_pages_node(nid, GFP_KERNEL | __GFP_ZERO | __GFP_THISNODE | __GFP_NOWARN, get_order(size))); if (!mem_info->vbase) @@ -797,14 +797,14 @@ static int core_imc_event_init(struct pe static int thread_imc_mem_alloc(int cpu_id, int size) { u64 ldbar_value, *local_mem = per_cpu(thread_imc_mem, cpu_id); - int phys_id = topology_physical_package_id(cpu_id); + int nid = cpu_to_node(cpu_id); if (!local_mem) { /* * This case could happen only once at start, since we dont * free the memory in cpu offline path. */ - local_mem = page_address(alloc_pages_node(phys_id, + local_mem = page_address(alloc_pages_node(nid, GFP_KERNEL | __GFP_ZERO | __GFP_THISNODE | __GFP_NOWARN, get_order(size))); if (!local_mem) Patches currently in stable-queue which might be from mpe(a)ellerman.id.au are queue-4.14/powerpc-perf-imc-use-cpu_to_node-not-topology_physical_package_id.patch queue-4.14/powerpc-64s-hash-fix-128tb-512tb-virtual-address-boundary-case-allocation.patch queue-4.14/powerpc-fix-boot-on-book3s_32-with-config_strict_kernel_rwx.patch queue-4.14/powerpc-64s-hash-fix-fork-with-512tb-process-address-space.patch queue-4.14/powerpc-mm-radix-fix-crashes-on-power9-dd1-with-radix-mmu-and-strict_rwx.patch queue-4.14/powerpc-64s-radix-fix-128tb-512tb-virtual-address-boundary-case-allocation.patch queue-4.14/powerpc-signal-properly-handle-return-value-from-uprobe_deny_signal.patch queue-4.14/powerpc-64s-hash-allow-map_fixed-allocations-to-cross-128tb-boundary.patch queue-4.14/powerpc-64s-hash-fix-512t-hint-detection-to-use-128t.patch queue-4.14/powerpc-64s-fix-masking-of-srr1-bits-on-instruction-fault.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "powerpc: Fix boot on BOOK3S_32 with CONFIG_STRICT_KERNEL_RWX" 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: Fix boot on BOOK3S_32 with CONFIG_STRICT_KERNEL_RWX 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-fix-boot-on-book3s_32-with-config_strict_kernel_rwx.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 252eb55816a6f69ef9464cad303cdb3326cdc61d Mon Sep 17 00:00:00 2001 From: Christophe Leroy <christophe.leroy(a)c-s.fr> Date: Tue, 21 Nov 2017 15:28:20 +0100 Subject: powerpc: Fix boot on BOOK3S_32 with CONFIG_STRICT_KERNEL_RWX From: Christophe Leroy <christophe.leroy(a)c-s.fr> commit 252eb55816a6f69ef9464cad303cdb3326cdc61d upstream. On powerpc32, patch_instruction() is called by apply_feature_fixups() which is called from early_init() There is the following note in front of early_init(): * Note that the kernel may be running at an address which is different * from the address that it was linked at, so we must use RELOC/PTRRELOC * to access static data (including strings). -- paulus Therefore, slab_is_available() cannot be called yet, and text_poke_area must be addressed with PTRRELOC() Fixes: 95902e6c8864 ("powerpc/mm: Implement STRICT_KERNEL_RWX on PPC32") Reported-by: Meelis Roos <mroos(a)linux.ee> Signed-off-by: Christophe Leroy <christophe.leroy(a)c-s.fr> Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/powerpc/lib/code-patching.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) --- a/arch/powerpc/lib/code-patching.c +++ b/arch/powerpc/lib/code-patching.c @@ -21,6 +21,7 @@ #include <asm/tlbflush.h> #include <asm/page.h> #include <asm/code-patching.h> +#include <asm/setup.h> static int __patch_instruction(unsigned int *addr, unsigned int instr) { @@ -146,11 +147,8 @@ int patch_instruction(unsigned int *addr * During early early boot patch_instruction is called * when text_poke_area is not ready, but we still need * to allow patching. We just do the plain old patching - * We use slab_is_available and per cpu read * via this_cpu_read - * of text_poke_area. Per-CPU areas might not be up early - * this can create problems with just using this_cpu_read() */ - if (!slab_is_available() || !this_cpu_read(text_poke_area)) + if (!this_cpu_read(*PTRRELOC(&text_poke_area))) return __patch_instruction(addr, instr); local_irq_save(flags); Patches currently in stable-queue which might be from christophe.leroy(a)c-s.fr are queue-4.14/powerpc-fix-boot-on-book3s_32-with-config_strict_kernel_rwx.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "powerpc/64s/radix: Fix 128TB-512TB virtual address boundary case allocation" 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/64s/radix: Fix 128TB-512TB virtual address boundary case allocation 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-64s-radix-fix-128tb-512tb-virtual-address-boundary-case-allocation.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 85e3f1adcb9d49300b0a943bb93f9604be375bfb Mon Sep 17 00:00:00 2001 From: Nicholas Piggin <npiggin(a)gmail.com> Date: Fri, 10 Nov 2017 04:27:39 +1100 Subject: powerpc/64s/radix: Fix 128TB-512TB virtual address boundary case allocation From: Nicholas Piggin <npiggin(a)gmail.com> commit 85e3f1adcb9d49300b0a943bb93f9604be375bfb upstream. Radix VA space allocations test addresses against mm->task_size which is 512TB, even in cases where the intention is to limit allocation to below 128TB. This results in mmap with a hint address below 128TB but address + length above 128TB succeeding when it should fail (as hash does after the previous patch). Set the high address limit to be considered up front, and base subsequent allocation checks on that consistently. Fixes: f4ea6dcb08ea ("powerpc/mm: Enable mappings above 128TB") Signed-off-by: Nicholas Piggin <npiggin(a)gmail.com> Reviewed-by: Aneesh Kumar K.V <aneesh.kumar(a)linux.vnet.ibm.com> Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/powerpc/mm/hugetlbpage-radix.c | 26 +++++++++++------ arch/powerpc/mm/mmap.c | 55 +++++++++++++++++++++--------------- 2 files changed, 50 insertions(+), 31 deletions(-) --- a/arch/powerpc/mm/hugetlbpage-radix.c +++ b/arch/powerpc/mm/hugetlbpage-radix.c @@ -49,17 +49,28 @@ radix__hugetlb_get_unmapped_area(struct struct mm_struct *mm = current->mm; struct vm_area_struct *vma; struct hstate *h = hstate_file(file); + int fixed = (flags & MAP_FIXED); + unsigned long high_limit; struct vm_unmapped_area_info info; - if (unlikely(addr > mm->context.addr_limit && addr < TASK_SIZE)) - mm->context.addr_limit = TASK_SIZE; + high_limit = DEFAULT_MAP_WINDOW; + if (addr >= high_limit || (fixed && (addr + len > high_limit))) + high_limit = TASK_SIZE; if (len & ~huge_page_mask(h)) return -EINVAL; - if (len > mm->task_size) + if (len > high_limit) return -ENOMEM; + if (fixed) { + if (addr > high_limit - len) + return -ENOMEM; + } - if (flags & MAP_FIXED) { + if (unlikely(addr > mm->context.addr_limit && + mm->context.addr_limit != TASK_SIZE)) + mm->context.addr_limit = TASK_SIZE; + + if (fixed) { if (prepare_hugepage_range(file, addr, len)) return -EINVAL; return addr; @@ -68,7 +79,7 @@ radix__hugetlb_get_unmapped_area(struct if (addr) { addr = ALIGN(addr, huge_page_size(h)); vma = find_vma(mm, addr); - if (mm->task_size - len >= addr && + if (high_limit - len >= addr && (!vma || addr + len <= vm_start_gap(vma))) return addr; } @@ -79,12 +90,9 @@ radix__hugetlb_get_unmapped_area(struct info.flags = VM_UNMAPPED_AREA_TOPDOWN; info.length = len; info.low_limit = PAGE_SIZE; - info.high_limit = current->mm->mmap_base; + info.high_limit = mm->mmap_base + (high_limit - DEFAULT_MAP_WINDOW); info.align_mask = PAGE_MASK & ~huge_page_mask(h); info.align_offset = 0; - if (addr > DEFAULT_MAP_WINDOW) - info.high_limit += mm->context.addr_limit - DEFAULT_MAP_WINDOW; - return vm_unmapped_area(&info); } --- a/arch/powerpc/mm/mmap.c +++ b/arch/powerpc/mm/mmap.c @@ -106,22 +106,32 @@ radix__arch_get_unmapped_area(struct fil { struct mm_struct *mm = current->mm; struct vm_area_struct *vma; + int fixed = (flags & MAP_FIXED); + unsigned long high_limit; struct vm_unmapped_area_info info; + high_limit = DEFAULT_MAP_WINDOW; + if (addr >= high_limit || (fixed && (addr + len > high_limit))) + high_limit = TASK_SIZE; + + if (len > high_limit) + return -ENOMEM; + if (fixed) { + if (addr > high_limit - len) + return -ENOMEM; + } + if (unlikely(addr > mm->context.addr_limit && mm->context.addr_limit != TASK_SIZE)) mm->context.addr_limit = TASK_SIZE; - if (len > mm->task_size - mmap_min_addr) - return -ENOMEM; - - if (flags & MAP_FIXED) + if (fixed) return addr; if (addr) { addr = PAGE_ALIGN(addr); vma = find_vma(mm, addr); - if (mm->task_size - len >= addr && addr >= mmap_min_addr && + if (high_limit - len >= addr && addr >= mmap_min_addr && (!vma || addr + len <= vm_start_gap(vma))) return addr; } @@ -129,13 +139,9 @@ radix__arch_get_unmapped_area(struct fil info.flags = 0; info.length = len; info.low_limit = mm->mmap_base; + info.high_limit = high_limit; info.align_mask = 0; - if (unlikely(addr > DEFAULT_MAP_WINDOW)) - info.high_limit = mm->context.addr_limit; - else - info.high_limit = DEFAULT_MAP_WINDOW; - return vm_unmapped_area(&info); } @@ -149,37 +155,42 @@ radix__arch_get_unmapped_area_topdown(st struct vm_area_struct *vma; struct mm_struct *mm = current->mm; unsigned long addr = addr0; + int fixed = (flags & MAP_FIXED); + unsigned long high_limit; struct vm_unmapped_area_info info; + high_limit = DEFAULT_MAP_WINDOW; + if (addr >= high_limit || (fixed && (addr + len > high_limit))) + high_limit = TASK_SIZE; + + if (len > high_limit) + return -ENOMEM; + if (fixed) { + if (addr > high_limit - len) + return -ENOMEM; + } + if (unlikely(addr > mm->context.addr_limit && mm->context.addr_limit != TASK_SIZE)) mm->context.addr_limit = TASK_SIZE; - /* requested length too big for entire address space */ - if (len > mm->task_size - mmap_min_addr) - return -ENOMEM; - - if (flags & MAP_FIXED) + if (fixed) return addr; - /* requesting a specific address */ if (addr) { addr = PAGE_ALIGN(addr); vma = find_vma(mm, addr); - if (mm->task_size - len >= addr && addr >= mmap_min_addr && - (!vma || addr + len <= vm_start_gap(vma))) + if (high_limit - len >= addr && addr >= mmap_min_addr && + (!vma || addr + len <= vm_start_gap(vma))) return addr; } info.flags = VM_UNMAPPED_AREA_TOPDOWN; info.length = len; info.low_limit = max(PAGE_SIZE, mmap_min_addr); - info.high_limit = mm->mmap_base; + info.high_limit = mm->mmap_base + (high_limit - DEFAULT_MAP_WINDOW); info.align_mask = 0; - if (addr > DEFAULT_MAP_WINDOW) - info.high_limit += mm->context.addr_limit - DEFAULT_MAP_WINDOW; - addr = vm_unmapped_area(&info); if (!(addr & ~PAGE_MASK)) return addr; Patches currently in stable-queue which might be from npiggin(a)gmail.com are queue-4.14/powerpc-64s-hash-fix-128tb-512tb-virtual-address-boundary-case-allocation.patch queue-4.14/powerpc-64s-hash-fix-fork-with-512tb-process-address-space.patch queue-4.14/powerpc-64s-radix-fix-128tb-512tb-virtual-address-boundary-case-allocation.patch queue-4.14/powerpc-64s-hash-allow-map_fixed-allocations-to-cross-128tb-boundary.patch queue-4.14/powerpc-64s-hash-fix-512t-hint-detection-to-use-128t.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "powerpc/64s/hash: Fix fork() with 512TB process address space" 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/64s/hash: Fix fork() with 512TB process address space 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-64s-hash-fix-fork-with-512tb-process-address-space.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 effc1b25088502fbd30305c79773de2d1f7470a6 Mon Sep 17 00:00:00 2001 From: Nicholas Piggin <npiggin(a)gmail.com> Date: Fri, 10 Nov 2017 04:27:37 +1100 Subject: powerpc/64s/hash: Fix fork() with 512TB process address space From: Nicholas Piggin <npiggin(a)gmail.com> commit effc1b25088502fbd30305c79773de2d1f7470a6 upstream. Hash unconditionally resets the addr_limit to default (128TB) when the mm context is initialised. If a process has > 128TB mappings when it forks, the child will not get the 512TB addr_limit, so accesses to valid > 128TB mappings will fail in the child. Fix this by only resetting the addr_limit to default if it was 0. Non zero indicates it was duplicated from the parent (0 means exec()). Fixes: f4ea6dcb08ea ("powerpc/mm: Enable mappings above 128TB") Signed-off-by: Nicholas Piggin <npiggin(a)gmail.com> Reviewed-by: Aneesh Kumar K.V <aneesh.kumar(a)linux.vnet.ibm.com> Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/powerpc/mm/mmu_context_book3s64.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) --- a/arch/powerpc/mm/mmu_context_book3s64.c +++ b/arch/powerpc/mm/mmu_context_book3s64.c @@ -93,11 +93,11 @@ static int hash__init_new_context(struct return index; /* - * We do switch_slb() early in fork, even before we setup the - * mm->context.addr_limit. Default to max task size so that we copy the - * default values to paca which will help us to handle slb miss early. + * In the case of exec, use the default limit, + * otherwise inherit it from the mm we are duplicating. */ - mm->context.addr_limit = DEFAULT_MAP_WINDOW_USER64; + if (!mm->context.addr_limit) + mm->context.addr_limit = DEFAULT_MAP_WINDOW_USER64; /* * The old code would re-promote on fork, we don't do that when using Patches currently in stable-queue which might be from npiggin(a)gmail.com are queue-4.14/powerpc-64s-hash-fix-128tb-512tb-virtual-address-boundary-case-allocation.patch queue-4.14/powerpc-64s-hash-fix-fork-with-512tb-process-address-space.patch queue-4.14/powerpc-64s-radix-fix-128tb-512tb-virtual-address-boundary-case-allocation.patch queue-4.14/powerpc-64s-hash-allow-map_fixed-allocations-to-cross-128tb-boundary.patch queue-4.14/powerpc-64s-hash-fix-512t-hint-detection-to-use-128t.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "powerpc/64s/hash: Fix 512T hint detection to use >= 128T" 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/64s/hash: Fix 512T hint detection to use >= 128T 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-64s-hash-fix-512t-hint-detection-to-use-128t.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 7ece370996b694ae263025e056ad785afc1be5ab Mon Sep 17 00:00:00 2001 From: Michael Ellerman <mpe(a)ellerman.id.au> Date: Mon, 13 Nov 2017 23:17:28 +1100 Subject: powerpc/64s/hash: Fix 512T hint detection to use >= 128T From: Michael Ellerman <mpe(a)ellerman.id.au> commit 7ece370996b694ae263025e056ad785afc1be5ab upstream. Currently userspace is able to request mmap() search between 128T-512T by specifying a hint address that is greater than 128T. But that means a hint of 128T exactly will return an address below 128T, which is confusing and wrong. So fix the logic to check the hint is greater than *or equal* to 128T. Fixes: f4ea6dcb08ea ("powerpc/mm: Enable mappings above 128TB") Suggested-by: Aneesh Kumar K.V <aneesh.kumar(a)linux.vnet.ibm.com> Suggested-by: Nicholas Piggin <npiggin(a)gmail.com> [mpe: Split out of Nick's bigger patch] Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/powerpc/mm/slice.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/arch/powerpc/mm/slice.c +++ b/arch/powerpc/mm/slice.c @@ -419,7 +419,7 @@ unsigned long slice_get_unmapped_area(un /* * Check if we need to expland slice area. */ - if (unlikely(addr > mm->context.addr_limit && + if (unlikely(addr >= mm->context.addr_limit && mm->context.addr_limit != TASK_SIZE)) { mm->context.addr_limit = TASK_SIZE; on_each_cpu(slice_flush_segments, mm, 1); @@ -427,7 +427,7 @@ unsigned long slice_get_unmapped_area(un /* * This mmap request can allocate upt to 512TB */ - if (addr > DEFAULT_MAP_WINDOW) + if (addr >= DEFAULT_MAP_WINDOW) high_limit = mm->context.addr_limit; else high_limit = DEFAULT_MAP_WINDOW; Patches currently in stable-queue which might be from mpe(a)ellerman.id.au are queue-4.14/powerpc-perf-imc-use-cpu_to_node-not-topology_physical_package_id.patch queue-4.14/powerpc-64s-hash-fix-128tb-512tb-virtual-address-boundary-case-allocation.patch queue-4.14/powerpc-fix-boot-on-book3s_32-with-config_strict_kernel_rwx.patch queue-4.14/powerpc-64s-hash-fix-fork-with-512tb-process-address-space.patch queue-4.14/powerpc-mm-radix-fix-crashes-on-power9-dd1-with-radix-mmu-and-strict_rwx.patch queue-4.14/powerpc-64s-radix-fix-128tb-512tb-virtual-address-boundary-case-allocation.patch queue-4.14/powerpc-signal-properly-handle-return-value-from-uprobe_deny_signal.patch queue-4.14/powerpc-64s-hash-allow-map_fixed-allocations-to-cross-128tb-boundary.patch queue-4.14/powerpc-64s-hash-fix-512t-hint-detection-to-use-128t.patch queue-4.14/powerpc-64s-fix-masking-of-srr1-bits-on-instruction-fault.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "powerpc/64s/hash: Fix 128TB-512TB virtual address boundary case allocation" 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/64s/hash: Fix 128TB-512TB virtual address boundary case allocation 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-64s-hash-fix-128tb-512tb-virtual-address-boundary-case-allocation.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 6a72dc038b615229a1b285829d6c8378d15c2347 Mon Sep 17 00:00:00 2001 From: Nicholas Piggin <npiggin(a)gmail.com> Date: Fri, 10 Nov 2017 04:27:36 +1100 Subject: powerpc/64s/hash: Fix 128TB-512TB virtual address boundary case allocation From: Nicholas Piggin <npiggin(a)gmail.com> commit 6a72dc038b615229a1b285829d6c8378d15c2347 upstream. When allocating VA space with a hint that crosses 128TB, the SLB addr_limit variable is not expanded if addr is not > 128TB, but the slice allocation looks at task_size, which is 512TB. This results in slice_check_fit() incorrectly succeeding because the slice_count truncates off bit 128 of the requested mask, so the comparison to the available mask succeeds. Fix this by using mm->context.addr_limit instead of mm->task_size for testing allocation limits. This causes such allocations to fail. Fixes: f4ea6dcb08ea ("powerpc/mm: Enable mappings above 128TB") Reported-by: Florian Weimer <fweimer(a)redhat.com> Signed-off-by: Nicholas Piggin <npiggin(a)gmail.com> Reviewed-by: Aneesh Kumar K.V <aneesh.kumar(a)linux.vnet.ibm.com> Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/powerpc/mm/slice.c | 50 +++++++++++++++++++++++------------------------- 1 file changed, 24 insertions(+), 26 deletions(-) --- a/arch/powerpc/mm/slice.c +++ b/arch/powerpc/mm/slice.c @@ -96,7 +96,7 @@ static int slice_area_is_free(struct mm_ { struct vm_area_struct *vma; - if ((mm->task_size - len) < addr) + if ((mm->context.addr_limit - len) < addr) return 0; vma = find_vma(mm, addr); return (!vma || (addr + len) <= vm_start_gap(vma)); @@ -133,7 +133,7 @@ static void slice_mask_for_free(struct m if (!slice_low_has_vma(mm, i)) ret->low_slices |= 1u << i; - if (mm->task_size <= SLICE_LOW_TOP) + if (mm->context.addr_limit <= SLICE_LOW_TOP) return; for (i = 0; i < GET_HIGH_SLICE_INDEX(mm->context.addr_limit); i++) @@ -412,25 +412,31 @@ unsigned long slice_get_unmapped_area(un struct slice_mask compat_mask; int fixed = (flags & MAP_FIXED); int pshift = max_t(int, mmu_psize_defs[psize].shift, PAGE_SHIFT); + unsigned long page_size = 1UL << pshift; struct mm_struct *mm = current->mm; unsigned long newaddr; unsigned long high_limit; - /* - * Check if we need to expland slice area. - */ - if (unlikely(addr >= mm->context.addr_limit && - mm->context.addr_limit != TASK_SIZE)) { - mm->context.addr_limit = TASK_SIZE; + high_limit = DEFAULT_MAP_WINDOW; + if (addr >= high_limit) + high_limit = TASK_SIZE; + + if (len > high_limit) + return -ENOMEM; + if (len & (page_size - 1)) + return -EINVAL; + if (fixed) { + if (addr & (page_size - 1)) + return -EINVAL; + if (addr > high_limit - len) + return -ENOMEM; + } + + if (high_limit > mm->context.addr_limit) { + mm->context.addr_limit = high_limit; on_each_cpu(slice_flush_segments, mm, 1); } - /* - * This mmap request can allocate upt to 512TB - */ - if (addr >= DEFAULT_MAP_WINDOW) - high_limit = mm->context.addr_limit; - else - high_limit = DEFAULT_MAP_WINDOW; + /* * init different masks */ @@ -446,27 +452,19 @@ unsigned long slice_get_unmapped_area(un /* Sanity checks */ BUG_ON(mm->task_size == 0); + BUG_ON(mm->context.addr_limit == 0); VM_BUG_ON(radix_enabled()); slice_dbg("slice_get_unmapped_area(mm=%p, psize=%d...\n", mm, psize); slice_dbg(" addr=%lx, len=%lx, flags=%lx, topdown=%d\n", addr, len, flags, topdown); - if (len > mm->task_size) - return -ENOMEM; - if (len & ((1ul << pshift) - 1)) - return -EINVAL; - if (fixed && (addr & ((1ul << pshift) - 1))) - return -EINVAL; - if (fixed && addr > (mm->task_size - len)) - return -ENOMEM; - /* If hint, make sure it matches our alignment restrictions */ if (!fixed && addr) { - addr = _ALIGN_UP(addr, 1ul << pshift); + addr = _ALIGN_UP(addr, page_size); slice_dbg(" aligned addr=%lx\n", addr); /* Ignore hint if it's too large or overlaps a VMA */ - if (addr > mm->task_size - len || + if (addr > high_limit - len || !slice_area_is_free(mm, addr, len)) addr = 0; } Patches currently in stable-queue which might be from npiggin(a)gmail.com are queue-4.14/powerpc-64s-hash-fix-128tb-512tb-virtual-address-boundary-case-allocation.patch queue-4.14/powerpc-64s-hash-fix-fork-with-512tb-process-address-space.patch queue-4.14/powerpc-64s-radix-fix-128tb-512tb-virtual-address-boundary-case-allocation.patch queue-4.14/powerpc-64s-hash-allow-map_fixed-allocations-to-cross-128tb-boundary.patch queue-4.14/powerpc-64s-hash-fix-512t-hint-detection-to-use-128t.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "powerpc/64s: Fix masking of SRR1 bits on instruction fault" 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/64s: Fix masking of SRR1 bits on instruction fault 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-64s-fix-masking-of-srr1-bits-on-instruction-fault.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 475b581ff57bc01437cbc680e281869918447763 Mon Sep 17 00:00:00 2001 From: Michael Ellerman <mpe(a)ellerman.id.au> Date: Tue, 14 Nov 2017 15:48:47 +1100 Subject: powerpc/64s: Fix masking of SRR1 bits on instruction fault From: Michael Ellerman <mpe(a)ellerman.id.au> commit 475b581ff57bc01437cbc680e281869918447763 upstream. On 64-bit Book3s, when we take an instruction fault the reason for the fault may be reported in SRR1. For data faults the reason is reported in DSISR (Data Storage Instruction Status Register). The reasons reported in each do not necessarily correspond, so we mask the SRR1 bits before copying them to the DSISR, which is then used by the page fault code. Prior to commit b4c001dc44f0 ("powerpc/mm: Use symbolic constants for filtering SRR1 bits on ISIs") we used a hard-coded mask of 0x58200000, which corresponds to: DSISR_NOHPTE 0x40000000 /* no translation found */ DSISR_NOEXEC_OR_G 0x10000000 /* exec of no-exec or guarded */ DSISR_PROTFAULT 0x08000000 /* protection fault */ DSISR_KEYFAULT 0x00200000 /* Storage Key fault */ That commit added a #define for the mask, DSISR_SRR1_MATCH_64S, but incorrectly used a different similarly named DSISR_BAD_FAULT_64S. This had the effect of changing the mask to 0xa43a0000, which omits everything but DSISR_KEYFAULT. Luckily this had no visible effect, because in practice we hardly use the DSISR bits. The lack of DSISR_NOHPTE means a TLB flush optimisation was missed in the native HPTE code, and DSISR_NOEXEC_OR_G and DSISR_PROTFAULT are both only used to trigger rare warnings. So we got lucky, but let's fix it. The new value only has bits between 17 and 30 set, so we can continue to use andis. Fixes: b4c001dc44f0 ("powerpc/mm: Use symbolic constants for filtering SRR1 bits on ISIs") Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/powerpc/kernel/exceptions-64s.S | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/powerpc/kernel/exceptions-64s.S +++ b/arch/powerpc/kernel/exceptions-64s.S @@ -542,7 +542,7 @@ EXC_COMMON_BEGIN(instruction_access_comm RECONCILE_IRQ_STATE(r10, r11) ld r12,_MSR(r1) ld r3,_NIP(r1) - andis. r4,r12,DSISR_BAD_FAULT_64S@h + andis. r4,r12,DSISR_SRR1_MATCH_64S@h li r5,0x400 std r3,_DAR(r1) std r4,_DSISR(r1) Patches currently in stable-queue which might be from mpe(a)ellerman.id.au are queue-4.14/powerpc-perf-imc-use-cpu_to_node-not-topology_physical_package_id.patch queue-4.14/powerpc-64s-hash-fix-128tb-512tb-virtual-address-boundary-case-allocation.patch queue-4.14/powerpc-fix-boot-on-book3s_32-with-config_strict_kernel_rwx.patch queue-4.14/powerpc-64s-hash-fix-fork-with-512tb-process-address-space.patch queue-4.14/powerpc-mm-radix-fix-crashes-on-power9-dd1-with-radix-mmu-and-strict_rwx.patch queue-4.14/powerpc-64s-radix-fix-128tb-512tb-virtual-address-boundary-case-allocation.patch queue-4.14/powerpc-signal-properly-handle-return-value-from-uprobe_deny_signal.patch queue-4.14/powerpc-64s-hash-allow-map_fixed-allocations-to-cross-128tb-boundary.patch queue-4.14/powerpc-64s-hash-fix-512t-hint-detection-to-use-128t.patch queue-4.14/powerpc-64s-fix-masking-of-srr1-bits-on-instruction-fault.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "powerpc/64s/hash: Allow MAP_FIXED allocations to cross 128TB boundary" 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/64s/hash: Allow MAP_FIXED allocations to cross 128TB boundary 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-64s-hash-allow-map_fixed-allocations-to-cross-128tb-boundary.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 35602f82d0c765f991420e319c8d3a596c921eb8 Mon Sep 17 00:00:00 2001 From: Nicholas Piggin <npiggin(a)gmail.com> Date: Fri, 10 Nov 2017 04:27:38 +1100 Subject: powerpc/64s/hash: Allow MAP_FIXED allocations to cross 128TB boundary From: Nicholas Piggin <npiggin(a)gmail.com> commit 35602f82d0c765f991420e319c8d3a596c921eb8 upstream. While mapping hints with a length that cross 128TB are disallowed, MAP_FIXED allocations that cross 128TB are allowed. These are failing on hash (on radix they succeed). Add an additional case for fixed mappings to expand the addr_limit when crossing 128TB. Fixes: f4ea6dcb08ea ("powerpc/mm: Enable mappings above 128TB") Signed-off-by: Nicholas Piggin <npiggin(a)gmail.com> Reviewed-by: Aneesh Kumar K.V <aneesh.kumar(a)linux.vnet.ibm.com> Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/powerpc/mm/slice.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/powerpc/mm/slice.c +++ b/arch/powerpc/mm/slice.c @@ -418,7 +418,7 @@ unsigned long slice_get_unmapped_area(un unsigned long high_limit; high_limit = DEFAULT_MAP_WINDOW; - if (addr >= high_limit) + if (addr >= high_limit || (fixed && (addr + len > high_limit))) high_limit = TASK_SIZE; if (len > high_limit) Patches currently in stable-queue which might be from npiggin(a)gmail.com are queue-4.14/powerpc-64s-hash-fix-128tb-512tb-virtual-address-boundary-case-allocation.patch queue-4.14/powerpc-64s-hash-fix-fork-with-512tb-process-address-space.patch queue-4.14/powerpc-64s-radix-fix-128tb-512tb-virtual-address-boundary-case-allocation.patch queue-4.14/powerpc-64s-hash-allow-map_fixed-allocations-to-cross-128tb-boundary.patch queue-4.14/powerpc-64s-hash-fix-512t-hint-detection-to-use-128t.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "media: venus: venc: fix bytesused v4l2_plane field" 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 media: venus: venc: fix bytesused v4l2_plane field 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: media-venus-venc-fix-bytesused-v4l2_plane-field.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 5232c37ce244db04fd50d160b92e40d2df46a2e9 Mon Sep 17 00:00:00 2001 From: Stanimir Varbanov <stanimir.varbanov(a)linaro.org> Date: Tue, 10 Oct 2017 09:52:36 +0200 Subject: media: venus: venc: fix bytesused v4l2_plane field From: Stanimir Varbanov <stanimir.varbanov(a)linaro.org> commit 5232c37ce244db04fd50d160b92e40d2df46a2e9 upstream. This fixes wrongly filled bytesused field of v4l2_plane structure by include data_offset in the plane, Also fill data_offset and bytesused for capture type of buffers only. Signed-off-by: Stanimir Varbanov <stanimir.varbanov(a)linaro.org> Signed-off-by: Hans Verkuil <hans.verkuil(a)cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab(a)osg.samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/media/platform/qcom/venus/venc.c | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) --- a/drivers/media/platform/qcom/venus/venc.c +++ b/drivers/media/platform/qcom/venus/venc.c @@ -963,13 +963,12 @@ static void venc_buf_done(struct venus_i if (!vbuf) return; - vb = &vbuf->vb2_buf; - vb->planes[0].bytesused = bytesused; - vb->planes[0].data_offset = data_offset; - vbuf->flags = flags; if (type == V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE) { + vb = &vbuf->vb2_buf; + vb2_set_plane_payload(vb, 0, bytesused + data_offset); + vb->planes[0].data_offset = data_offset; vb->timestamp = timestamp_us * NSEC_PER_USEC; vbuf->sequence = inst->sequence_cap++; } else { Patches currently in stable-queue which might be from stanimir.varbanov(a)linaro.org are queue-4.14/media-venus-venc-fix-bytesused-v4l2_plane-field.patch queue-4.14/media-venus-reimplement-decoder-stop-command.patch queue-4.14/media-venus-fix-wrong-size-on-dma_free.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "parisc: Fix validity check of pointer size argument in new CAS implementation" 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 parisc: Fix validity check of pointer size argument in new CAS implementation 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: parisc-fix-validity-check-of-pointer-size-argument-in-new-cas-implementation.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 05f016d2ca7a4fab99d5d5472168506ddf95e74f Mon Sep 17 00:00:00 2001 From: John David Anglin <dave.anglin(a)bell.net> Date: Sat, 11 Nov 2017 17:11:16 -0500 Subject: parisc: Fix validity check of pointer size argument in new CAS implementation From: John David Anglin <dave.anglin(a)bell.net> commit 05f016d2ca7a4fab99d5d5472168506ddf95e74f upstream. As noted by Christoph Biedl, passing a pointer size of 4 in the new CAS implementation causes a kernel crash. The attached patch corrects the off by one error in the argument validity check. In reviewing the code, I noticed that we only perform word operations with the pointer size argument. The subi instruction intentionally uses a word condition on 64-bit kernels. Nullification was used instead of a cmpib instruction as the branch should never be taken. The shlw pseudo-operation generates a depw,z instruction and it clears the target before doing a shift left word deposit. Thus, we don't need to clip the upper 32 bits of this argument on 64-bit kernels. Tested with a gcc testsuite run with a 64-bit kernel. The gcc atomic code in libgcc is the only direct user of the new CAS implementation that I am aware of. Signed-off-by: John David Anglin <dave.anglin(a)bell.net> Signed-off-by: Helge Deller <deller(a)gmx.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/parisc/kernel/syscall.S | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) --- a/arch/parisc/kernel/syscall.S +++ b/arch/parisc/kernel/syscall.S @@ -690,15 +690,15 @@ cas_action: /* ELF32 Process entry path */ lws_compare_and_swap_2: #ifdef CONFIG_64BIT - /* Clip the input registers */ + /* Clip the input registers. We don't need to clip %r23 as we + only use it for word operations */ depdi 0, 31, 32, %r26 depdi 0, 31, 32, %r25 depdi 0, 31, 32, %r24 - depdi 0, 31, 32, %r23 #endif /* Check the validity of the size pointer */ - subi,>>= 4, %r23, %r0 + subi,>>= 3, %r23, %r0 b,n lws_exit_nosys /* Jump to the functions which will load the old and new values into Patches currently in stable-queue which might be from dave.anglin(a)bell.net are queue-4.14/parisc-fix-validity-check-of-pointer-size-argument-in-new-cas-implementation.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "media: v4l2-ctrl: Fix flags field on Control events" 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 media: v4l2-ctrl: Fix flags field on Control events 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: media-v4l2-ctrl-fix-flags-field-on-control-events.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 9cac9d2fb2fe0e0cadacdb94415b3fe49e3f724f Mon Sep 17 00:00:00 2001 From: Ricardo Ribalda <ricardo.ribalda(a)gmail.com> Date: Tue, 17 Oct 2017 11:48:50 -0400 Subject: media: v4l2-ctrl: Fix flags field on Control events From: Ricardo Ribalda Delgado <ricardo.ribalda(a)gmail.com> commit 9cac9d2fb2fe0e0cadacdb94415b3fe49e3f724f upstream. VIDIOC_DQEVENT and VIDIOC_QUERY_EXT_CTRL should give the same output for the control flags field. This patch creates a new function user_flags(), that calculates the user exported flags value (which is different than the kernel internal flags structure). This function is then used by all the code that exports the internal flags to userspace. Reported-by: Dimitrios Katsaros <patcherwork(a)gmail.com> Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda(a)gmail.com> Signed-off-by: Hans Verkuil <hans.verkuil(a)cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/media/v4l2-core/v4l2-ctrls.c | 16 ++++++++++++---- 1 file changed, 12 insertions(+), 4 deletions(-) --- a/drivers/media/v4l2-core/v4l2-ctrls.c +++ b/drivers/media/v4l2-core/v4l2-ctrls.c @@ -1227,6 +1227,16 @@ void v4l2_ctrl_fill(u32 id, const char * } EXPORT_SYMBOL(v4l2_ctrl_fill); +static u32 user_flags(const struct v4l2_ctrl *ctrl) +{ + u32 flags = ctrl->flags; + + if (ctrl->is_ptr) + flags |= V4L2_CTRL_FLAG_HAS_PAYLOAD; + + return flags; +} + static void fill_event(struct v4l2_event *ev, struct v4l2_ctrl *ctrl, u32 changes) { memset(ev->reserved, 0, sizeof(ev->reserved)); @@ -1234,7 +1244,7 @@ static void fill_event(struct v4l2_event ev->id = ctrl->id; ev->u.ctrl.changes = changes; ev->u.ctrl.type = ctrl->type; - ev->u.ctrl.flags = ctrl->flags; + ev->u.ctrl.flags = user_flags(ctrl); if (ctrl->is_ptr) ev->u.ctrl.value64 = 0; else @@ -2577,10 +2587,8 @@ int v4l2_query_ext_ctrl(struct v4l2_ctrl else qc->id = ctrl->id; strlcpy(qc->name, ctrl->name, sizeof(qc->name)); - qc->flags = ctrl->flags; + qc->flags = user_flags(ctrl); qc->type = ctrl->type; - if (ctrl->is_ptr) - qc->flags |= V4L2_CTRL_FLAG_HAS_PAYLOAD; qc->elem_size = ctrl->elem_size; qc->elems = ctrl->elems; qc->nr_of_dims = ctrl->nr_of_dims; Patches currently in stable-queue which might be from ricardo.ribalda(a)gmail.com are queue-4.14/media-v4l2-ctrl-fix-flags-field-on-control-events.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "media: venus: reimplement decoder stop command" 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 media: venus: reimplement decoder stop command 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: media-venus-reimplement-decoder-stop-command.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 e69b987a97599456b95b5fef4aca8dcdb1505aea Mon Sep 17 00:00:00 2001 From: Stanimir Varbanov <stanimir.varbanov(a)linaro.org> Date: Fri, 13 Oct 2017 16:13:17 +0200 Subject: media: venus: reimplement decoder stop command From: Stanimir Varbanov <stanimir.varbanov(a)linaro.org> commit e69b987a97599456b95b5fef4aca8dcdb1505aea upstream. This addresses the wrong behavior of decoder stop command by rewriting it. These new implementation enqueue an empty buffer on the decoder input buffer queue to signal end-of-stream. The client should stop queuing buffers on the V4L2 Output queue and continue queuing/dequeuing buffers on Capture queue. This process will continue until the client receives a buffer with V4L2_BUF_FLAG_LAST flag raised, which means that this is last decoded buffer with data. Signed-off-by: Stanimir Varbanov <stanimir.varbanov(a)linaro.org> Tested-by: Nicolas Dufresne <nicolas.dufresne(a)collabora.com> Signed-off-by: Hans Verkuil <hans.verkuil(a)cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab(a)osg.samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/media/platform/qcom/venus/core.h | 2 - drivers/media/platform/qcom/venus/helpers.c | 7 ----- drivers/media/platform/qcom/venus/hfi.c | 1 drivers/media/platform/qcom/venus/vdec.c | 34 ++++++++++++++++++---------- 4 files changed, 24 insertions(+), 20 deletions(-) --- a/drivers/media/platform/qcom/venus/core.h +++ b/drivers/media/platform/qcom/venus/core.h @@ -194,7 +194,6 @@ struct venus_buffer { * @fh: a holder of v4l file handle structure * @streamon_cap: stream on flag for capture queue * @streamon_out: stream on flag for output queue - * @cmd_stop: a flag to signal encoder/decoder commands * @width: current capture width * @height: current capture height * @out_width: current output width @@ -258,7 +257,6 @@ struct venus_inst { } controls; struct v4l2_fh fh; unsigned int streamon_cap, streamon_out; - bool cmd_stop; u32 width; u32 height; u32 out_width; --- a/drivers/media/platform/qcom/venus/helpers.c +++ b/drivers/media/platform/qcom/venus/helpers.c @@ -623,13 +623,6 @@ void venus_helper_vb2_buf_queue(struct v mutex_lock(&inst->lock); - if (inst->cmd_stop) { - vbuf->flags |= V4L2_BUF_FLAG_LAST; - v4l2_m2m_buf_done(vbuf, VB2_BUF_STATE_DONE); - inst->cmd_stop = false; - goto unlock; - } - v4l2_m2m_buf_queue(m2m_ctx, vbuf); if (!(inst->streamon_out & inst->streamon_cap)) --- a/drivers/media/platform/qcom/venus/hfi.c +++ b/drivers/media/platform/qcom/venus/hfi.c @@ -484,6 +484,7 @@ int hfi_session_process_buf(struct venus return -EINVAL; } +EXPORT_SYMBOL_GPL(hfi_session_process_buf); irqreturn_t hfi_isr_thread(int irq, void *dev_id) { --- a/drivers/media/platform/qcom/venus/vdec.c +++ b/drivers/media/platform/qcom/venus/vdec.c @@ -469,8 +469,14 @@ static int vdec_subscribe_event(struct v static int vdec_try_decoder_cmd(struct file *file, void *fh, struct v4l2_decoder_cmd *cmd) { - if (cmd->cmd != V4L2_DEC_CMD_STOP) + switch (cmd->cmd) { + case V4L2_DEC_CMD_STOP: + if (cmd->flags & V4L2_DEC_CMD_STOP_TO_BLACK) + return -EINVAL; + break; + default: return -EINVAL; + } return 0; } @@ -479,6 +485,7 @@ static int vdec_decoder_cmd(struct file *file, void *fh, struct v4l2_decoder_cmd *cmd) { struct venus_inst *inst = to_inst(file); + struct hfi_frame_data fdata = {0}; int ret; ret = vdec_try_decoder_cmd(file, fh, cmd); @@ -486,12 +493,23 @@ vdec_decoder_cmd(struct file *file, void return ret; mutex_lock(&inst->lock); - inst->cmd_stop = true; - mutex_unlock(&inst->lock); - hfi_session_flush(inst); + /* + * Implement V4L2_DEC_CMD_STOP by enqueue an empty buffer on decoder + * input to signal EOS. + */ + if (!(inst->streamon_out & inst->streamon_cap)) + goto unlock; + + fdata.buffer_type = HFI_BUFFER_INPUT; + fdata.flags |= HFI_BUFFERFLAG_EOS; + fdata.device_addr = 0xdeadbeef; - return 0; + ret = hfi_session_process_buf(inst, &fdata); + +unlock: + mutex_unlock(&inst->lock); + return ret; } static const struct v4l2_ioctl_ops vdec_ioctl_ops = { @@ -718,7 +736,6 @@ static int vdec_start_streaming(struct v inst->reconfig = false; inst->sequence_cap = 0; inst->sequence_out = 0; - inst->cmd_stop = false; ret = vdec_init_session(inst); if (ret) @@ -807,11 +824,6 @@ static void vdec_buf_done(struct venus_i vb->timestamp = timestamp_us * NSEC_PER_USEC; vbuf->sequence = inst->sequence_cap++; - if (inst->cmd_stop) { - vbuf->flags |= V4L2_BUF_FLAG_LAST; - inst->cmd_stop = false; - } - if (vbuf->flags & V4L2_BUF_FLAG_LAST) { const struct v4l2_event ev = { .type = V4L2_EVENT_EOS }; Patches currently in stable-queue which might be from stanimir.varbanov(a)linaro.org are queue-4.14/media-venus-venc-fix-bytesused-v4l2_plane-field.patch queue-4.14/media-venus-reimplement-decoder-stop-command.patch queue-4.14/media-venus-fix-wrong-size-on-dma_free.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "media: venus: fix wrong size on dma_free" 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 media: venus: fix wrong size on dma_free 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: media-venus-fix-wrong-size-on-dma_free.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 cd1a77e3c9cc6dbb57f02aa50e1740fc144d2dad Mon Sep 17 00:00:00 2001 From: Stanimir Varbanov <stanimir.varbanov(a)linaro.org> Date: Mon, 9 Oct 2017 14:24:57 +0200 Subject: media: venus: fix wrong size on dma_free From: Stanimir Varbanov <stanimir.varbanov(a)linaro.org> commit cd1a77e3c9cc6dbb57f02aa50e1740fc144d2dad upstream. This change will fix an issue with dma_free size found with DMA API debug enabled. Signed-off-by: Stanimir Varbanov <stanimir.varbanov(a)linaro.org> Signed-off-by: Hans Verkuil <hans.verkuil(a)cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab(a)osg.samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/media/platform/qcom/venus/hfi_venus.c | 12 ++++-------- 1 file changed, 4 insertions(+), 8 deletions(-) --- a/drivers/media/platform/qcom/venus/hfi_venus.c +++ b/drivers/media/platform/qcom/venus/hfi_venus.c @@ -344,7 +344,7 @@ static int venus_alloc(struct venus_hfi_ desc->attrs = DMA_ATTR_WRITE_COMBINE; desc->size = ALIGN(size, SZ_4K); - desc->kva = dma_alloc_attrs(dev, size, &desc->da, GFP_KERNEL, + desc->kva = dma_alloc_attrs(dev, desc->size, &desc->da, GFP_KERNEL, desc->attrs); if (!desc->kva) return -ENOMEM; @@ -710,10 +710,8 @@ static int venus_interface_queues_init(s if (ret) return ret; - hdev->ifaceq_table.kva = desc.kva; - hdev->ifaceq_table.da = desc.da; - hdev->ifaceq_table.size = IFACEQ_TABLE_SIZE; - offset = hdev->ifaceq_table.size; + hdev->ifaceq_table = desc; + offset = IFACEQ_TABLE_SIZE; for (i = 0; i < IFACEQ_NUM; i++) { queue = &hdev->queues[i]; @@ -755,9 +753,7 @@ static int venus_interface_queues_init(s if (ret) { hdev->sfr.da = 0; } else { - hdev->sfr.da = desc.da; - hdev->sfr.kva = desc.kva; - hdev->sfr.size = ALIGNED_SFR_SIZE; + hdev->sfr = desc; sfr = hdev->sfr.kva; sfr->buf_size = ALIGNED_SFR_SIZE; } Patches currently in stable-queue which might be from stanimir.varbanov(a)linaro.org are queue-4.14/media-venus-venc-fix-bytesused-v4l2_plane-field.patch queue-4.14/media-venus-reimplement-decoder-stop-command.patch queue-4.14/media-venus-fix-wrong-size-on-dma_free.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "media: rc: nec decoder should not send both repeat and keycode" 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 media: rc: nec decoder should not send both repeat and keycode 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: media-rc-nec-decoder-should-not-send-both-repeat-and-keycode.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 829bbf268894d0866bb9dd2b1e430cfa5c5f0779 Mon Sep 17 00:00:00 2001 From: Sean Young <sean(a)mess.org> Date: Sun, 1 Oct 2017 16:38:29 -0400 Subject: media: rc: nec decoder should not send both repeat and keycode From: Sean Young <sean(a)mess.org> commit 829bbf268894d0866bb9dd2b1e430cfa5c5f0779 upstream. When receiving an nec repeat, rc_repeat() is called and then rc_keydown() with the last decoded scancode. That last call is redundant. Fixes: 265a2988d202 ("media: rc-core: consistent use of rc_repeat()") Signed-off-by: Sean Young <sean(a)mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/media/rc/ir-nec-decoder.c | 31 ++++++++++++++++++------------- 1 file changed, 18 insertions(+), 13 deletions(-) --- a/drivers/media/rc/ir-nec-decoder.c +++ b/drivers/media/rc/ir-nec-decoder.c @@ -87,8 +87,6 @@ static int ir_nec_decode(struct rc_dev * data->state = STATE_BIT_PULSE; return 0; } else if (eq_margin(ev.duration, NEC_REPEAT_SPACE, NEC_UNIT / 2)) { - rc_repeat(dev); - IR_dprintk(1, "Repeat last key\n"); data->state = STATE_TRAILER_PULSE; return 0; } @@ -151,19 +149,26 @@ static int ir_nec_decode(struct rc_dev * if (!geq_margin(ev.duration, NEC_TRAILER_SPACE, NEC_UNIT / 2)) break; - address = bitrev8((data->bits >> 24) & 0xff); - not_address = bitrev8((data->bits >> 16) & 0xff); - command = bitrev8((data->bits >> 8) & 0xff); - not_command = bitrev8((data->bits >> 0) & 0xff); - - scancode = ir_nec_bytes_to_scancode(address, not_address, - command, not_command, - &rc_proto); + if (data->count == NEC_NBITS) { + address = bitrev8((data->bits >> 24) & 0xff); + not_address = bitrev8((data->bits >> 16) & 0xff); + command = bitrev8((data->bits >> 8) & 0xff); + not_command = bitrev8((data->bits >> 0) & 0xff); + + scancode = ir_nec_bytes_to_scancode(address, + not_address, + command, + not_command, + &rc_proto); + + if (data->is_nec_x) + data->necx_repeat = true; - if (data->is_nec_x) - data->necx_repeat = true; + rc_keydown(dev, rc_proto, scancode, 0); + } else { + rc_repeat(dev); + } - rc_keydown(dev, rc_proto, scancode, 0); data->state = STATE_INACTIVE; return 0; } Patches currently in stable-queue which might be from sean(a)mess.org are queue-4.14/media-rc-check-for-integer-overflow.patch queue-4.14/media-rc-nec-decoder-should-not-send-both-repeat-and-keycode.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "media: rc: check for integer overflow" 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 media: rc: check for integer overflow 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: media-rc-check-for-integer-overflow.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 3e45067f94bbd61dec0619b1c32744eb0de480c8 Mon Sep 17 00:00:00 2001 From: Sean Young <sean(a)mess.org> Date: Sun, 8 Oct 2017 14:18:52 -0400 Subject: media: rc: check for integer overflow From: Sean Young <sean(a)mess.org> commit 3e45067f94bbd61dec0619b1c32744eb0de480c8 upstream. The ioctl LIRC_SET_REC_TIMEOUT would set a timeout of 704ns if called with a timeout of 4294968us. Signed-off-by: Sean Young <sean(a)mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/media/rc/ir-lirc-codec.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) --- a/drivers/media/rc/ir-lirc-codec.c +++ b/drivers/media/rc/ir-lirc-codec.c @@ -298,11 +298,14 @@ static long ir_lirc_ioctl(struct file *f if (!dev->max_timeout) return -ENOTTY; + /* Check for multiply overflow */ + if (val > U32_MAX / 1000) + return -EINVAL; + tmp = val * 1000; - if (tmp < dev->min_timeout || - tmp > dev->max_timeout) - return -EINVAL; + if (tmp < dev->min_timeout || tmp > dev->max_timeout) + return -EINVAL; if (dev->s_timeout) ret = dev->s_timeout(dev, tmp); Patches currently in stable-queue which might be from sean(a)mess.org are queue-4.14/media-rc-check-for-integer-overflow.patch queue-4.14/media-rc-nec-decoder-should-not-send-both-repeat-and-keycode.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "media: Don't do DMA on stack for firmware upload in the AS102 driver" 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 media: Don't do DMA on stack for firmware upload in the AS102 driver 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: media-don-t-do-dma-on-stack-for-firmware-upload-in-the-as102-driver.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 b3120d2cc447ee77b9d69bf4ad7b452c9adb4d39 Mon Sep 17 00:00:00 2001 From: Michele Baldessari <michele(a)acksyn.org> Date: Mon, 6 Nov 2017 08:50:22 -0500 Subject: media: Don't do DMA on stack for firmware upload in the AS102 driver From: Michele Baldessari <michele(a)acksyn.org> commit b3120d2cc447ee77b9d69bf4ad7b452c9adb4d39 upstream. Firmware load on AS102 is using the stack which is not allowed any longer. We currently fail with: kernel: transfer buffer not dma capable kernel: ------------[ cut here ]------------ kernel: WARNING: CPU: 0 PID: 598 at drivers/usb/core/hcd.c:1595 usb_hcd_map_urb_for_dma+0x41d/0x620 kernel: Modules linked in: amd64_edac_mod(-) edac_mce_amd as102_fe dvb_as102(+) kvm_amd kvm snd_hda_codec_realtek dvb_core snd_hda_codec_generic snd_hda_codec_hdmi snd_hda_intel snd_hda_codec irqbypass crct10dif_pclmul crc32_pclmul snd_hda_core snd_hwdep snd_seq ghash_clmulni_intel sp5100_tco fam15h_power wmi k10temp i2c_piix4 snd_seq_device snd_pcm snd_timer parport_pc parport tpm_infineon snd tpm_tis soundcore tpm_tis_core tpm shpchp acpi_cpufreq xfs libcrc32c amdgpu amdkfd amd_iommu_v2 radeon hid_logitech_hidpp i2c_algo_bit drm_kms_helper crc32c_intel ttm drm r8169 mii hid_logitech_dj kernel: CPU: 0 PID: 598 Comm: systemd-udevd Not tainted 4.13.10-200.fc26.x86_64 #1 kernel: Hardware name: ASUS All Series/AM1I-A, BIOS 0505 03/13/2014 kernel: task: ffff979933b24c80 task.stack: ffffaf83413a4000 kernel: RIP: 0010:usb_hcd_map_urb_for_dma+0x41d/0x620 systemd-fsck[659]: /dev/sda2: clean, 49/128016 files, 268609/512000 blocks kernel: RSP: 0018:ffffaf83413a7728 EFLAGS: 00010282 systemd-udevd[604]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable. kernel: RAX: 000000000000001f RBX: ffff979930bce780 RCX: 0000000000000000 kernel: RDX: 0000000000000000 RSI: ffff97993ec0e118 RDI: ffff97993ec0e118 kernel: RBP: ffffaf83413a7768 R08: 000000000000039a R09: 0000000000000000 kernel: R10: 0000000000000001 R11: 00000000ffffffff R12: 00000000fffffff5 kernel: R13: 0000000001400000 R14: 0000000000000001 R15: ffff979930806800 kernel: FS: 00007effaca5c8c0(0000) GS:ffff97993ec00000(0000) knlGS:0000000000000000 kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 kernel: CR2: 00007effa9fca962 CR3: 0000000233089000 CR4: 00000000000406f0 kernel: Call Trace: kernel: usb_hcd_submit_urb+0x493/0xb40 kernel: ? page_cache_tree_insert+0x100/0x100 kernel: ? xfs_iunlock+0xd5/0x100 [xfs] kernel: ? xfs_file_buffered_aio_read+0x57/0xc0 [xfs] kernel: usb_submit_urb+0x22d/0x560 kernel: usb_start_wait_urb+0x6e/0x180 kernel: usb_bulk_msg+0xb8/0x160 kernel: as102_send_ep1+0x49/0xe0 [dvb_as102] kernel: ? devres_add+0x3f/0x50 kernel: as102_firmware_upload.isra.0+0x1dc/0x210 [dvb_as102] kernel: as102_fw_upload+0xb6/0x1f0 [dvb_as102] kernel: as102_dvb_register+0x2af/0x2d0 [dvb_as102] kernel: as102_usb_probe+0x1f3/0x260 [dvb_as102] kernel: usb_probe_interface+0x124/0x300 kernel: driver_probe_device+0x2ff/0x450 kernel: __driver_attach+0xa4/0xe0 kernel: ? driver_probe_device+0x450/0x450 kernel: bus_for_each_dev+0x6e/0xb0 kernel: driver_attach+0x1e/0x20 kernel: bus_add_driver+0x1c7/0x270 kernel: driver_register+0x60/0xe0 kernel: usb_register_driver+0x81/0x150 kernel: ? 0xffffffffc0807000 kernel: as102_usb_driver_init+0x1e/0x1000 [dvb_as102] kernel: do_one_initcall+0x50/0x190 kernel: ? __vunmap+0x81/0xb0 kernel: ? kfree+0x154/0x170 kernel: ? kmem_cache_alloc_trace+0x15f/0x1c0 kernel: ? do_init_module+0x27/0x1e9 kernel: do_init_module+0x5f/0x1e9 kernel: load_module+0x2602/0x2c30 kernel: SYSC_init_module+0x170/0x1a0 kernel: ? SYSC_init_module+0x170/0x1a0 kernel: SyS_init_module+0xe/0x10 kernel: do_syscall_64+0x67/0x140 kernel: entry_SYSCALL64_slow_path+0x25/0x25 kernel: RIP: 0033:0x7effab6cf3ea kernel: RSP: 002b:00007fff5cfcbbc8 EFLAGS: 00000246 ORIG_RAX: 00000000000000af kernel: RAX: ffffffffffffffda RBX: 00005569e0b83760 RCX: 00007effab6cf3ea kernel: RDX: 00007effac2099c5 RSI: 0000000000009a13 RDI: 00005569e0b98c50 kernel: RBP: 00007effac2099c5 R08: 00005569e0b83ed0 R09: 0000000000001d80 kernel: R10: 00007effab98db00 R11: 0000000000000246 R12: 00005569e0b98c50 kernel: R13: 00005569e0b81c60 R14: 0000000000020000 R15: 00005569dfadfdf7 kernel: Code: 48 39 c8 73 30 80 3d 59 60 9d 00 00 41 bc f5 ff ff ff 0f 85 26 ff ff ff 48 c7 c7 b8 6b d0 92 c6 05 3f 60 9d 00 01 e8 24 3d ad ff <0f> ff 8b 53 64 e9 09 ff ff ff 65 48 8b 0c 25 00 d3 00 00 48 8b kernel: ---[ end trace c4cae366180e70ec ]--- kernel: as10x_usb: error during firmware upload part1 Let's allocate the the structure dynamically so we can get the firmware loaded correctly: [ 14.243057] as10x_usb: firmware: as102_data1_st.hex loaded with success [ 14.500777] as10x_usb: firmware: as102_data2_st.hex loaded with success Signed-off-by: Michele Baldessari <michele(a)acksyn.org> Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/media/usb/as102/as102_fw.c | 28 +++++++++++++++++----------- 1 file changed, 17 insertions(+), 11 deletions(-) --- a/drivers/media/usb/as102/as102_fw.c +++ b/drivers/media/usb/as102/as102_fw.c @@ -101,18 +101,23 @@ static int as102_firmware_upload(struct unsigned char *cmd, const struct firmware *firmware) { - struct as10x_fw_pkt_t fw_pkt; + struct as10x_fw_pkt_t *fw_pkt; int total_read_bytes = 0, errno = 0; unsigned char addr_has_changed = 0; + fw_pkt = kmalloc(sizeof(*fw_pkt), GFP_KERNEL); + if (!fw_pkt) + return -ENOMEM; + + for (total_read_bytes = 0; total_read_bytes < firmware->size; ) { int read_bytes = 0, data_len = 0; /* parse intel hex line */ read_bytes = parse_hex_line( (u8 *) (firmware->data + total_read_bytes), - fw_pkt.raw.address, - fw_pkt.raw.data, + fw_pkt->raw.address, + fw_pkt->raw.data, &data_len, &addr_has_changed); @@ -122,28 +127,28 @@ static int as102_firmware_upload(struct /* detect the end of file */ total_read_bytes += read_bytes; if (total_read_bytes == firmware->size) { - fw_pkt.u.request[0] = 0x00; - fw_pkt.u.request[1] = 0x03; + fw_pkt->u.request[0] = 0x00; + fw_pkt->u.request[1] = 0x03; /* send EOF command */ errno = bus_adap->ops->upload_fw_pkt(bus_adap, (uint8_t *) - &fw_pkt, 2, 0); + fw_pkt, 2, 0); if (errno < 0) goto error; } else { if (!addr_has_changed) { /* prepare command to send */ - fw_pkt.u.request[0] = 0x00; - fw_pkt.u.request[1] = 0x01; + fw_pkt->u.request[0] = 0x00; + fw_pkt->u.request[1] = 0x01; - data_len += sizeof(fw_pkt.u.request); - data_len += sizeof(fw_pkt.raw.address); + data_len += sizeof(fw_pkt->u.request); + data_len += sizeof(fw_pkt->raw.address); /* send cmd to device */ errno = bus_adap->ops->upload_fw_pkt(bus_adap, (uint8_t *) - &fw_pkt, + fw_pkt, data_len, 0); if (errno < 0) @@ -152,6 +157,7 @@ static int as102_firmware_upload(struct } } error: + kfree(fw_pkt); return (errno == 0) ? total_read_bytes : errno; } Patches currently in stable-queue which might be from michele(a)acksyn.org are queue-4.14/media-don-t-do-dma-on-stack-for-firmware-upload-in-the-as102-driver.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "ixgbevf: Use smp_rmb rather than read_barrier_depends" 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 ixgbevf: Use smp_rmb rather than read_barrier_depends 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: ixgbevf-use-smp_rmb-rather-than-read_barrier_depends.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 ae0c585d93dfaf923d2c7eb44b2c3ab92854ea9b Mon Sep 17 00:00:00 2001 From: Brian King <brking(a)linux.vnet.ibm.com> Date: Fri, 17 Nov 2017 11:05:45 -0600 Subject: ixgbevf: Use smp_rmb rather than read_barrier_depends From: Brian King <brking(a)linux.vnet.ibm.com> commit ae0c585d93dfaf923d2c7eb44b2c3ab92854ea9b upstream. The original issue being fixed in this patch was seen with the ixgbe driver, but the same issue exists with ixgbevf as well, as the code is very similar. read_barrier_depends is not sufficient to ensure loads following it are not speculatively loaded out of order by the CPU, which can result in stale data being loaded, causing potential system crashes. Signed-off-by: Brian King <brking(a)linux.vnet.ibm.com> Acked-by: Jesse Brandeburg <jesse.brandeburg(a)intel.com> Tested-by: Andrew Bowers <andrewx.bowers(a)intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher(a)intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c +++ b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c @@ -326,7 +326,7 @@ static bool ixgbevf_clean_tx_irq(struct break; /* prevent any other reads prior to eop_desc */ - read_barrier_depends(); + smp_rmb(); /* if DD is not set pending work has not been completed */ if (!(eop_desc->wb.status & cpu_to_le32(IXGBE_TXD_STAT_DD))) Patches currently in stable-queue which might be from brking(a)linux.vnet.ibm.com are queue-4.14/i40evf-use-smp_rmb-rather-than-read_barrier_depends.patch queue-4.14/igb-use-smp_rmb-rather-than-read_barrier_depends.patch queue-4.14/ixgbevf-use-smp_rmb-rather-than-read_barrier_depends.patch queue-4.14/igbvf-use-smp_rmb-rather-than-read_barrier_depends.patch queue-4.14/fm10k-use-smp_rmb-rather-than-read_barrier_depends.patch queue-4.14/ixgbe-fix-skb-list-corruption-on-power-systems.patch queue-4.14/i40e-use-smp_rmb-rather-than-read_barrier_depends.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "ixgbe: Fix skb list corruption on Power systems" 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 ixgbe: Fix skb list corruption on Power systems 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: ixgbe-fix-skb-list-corruption-on-power-systems.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 0a9a17e3bb4564caf4bfe2a6783ae1287667d188 Mon Sep 17 00:00:00 2001 From: Brian King <brking(a)linux.vnet.ibm.com> Date: Fri, 17 Nov 2017 11:05:43 -0600 Subject: ixgbe: Fix skb list corruption on Power systems From: Brian King <brking(a)linux.vnet.ibm.com> commit 0a9a17e3bb4564caf4bfe2a6783ae1287667d188 upstream. This patch fixes an issue seen on Power systems with ixgbe which results in skb list corruption and an eventual kernel oops. The following is what was observed: CPU 1 CPU2 ============================ ============================ 1: ixgbe_xmit_frame_ring ixgbe_clean_tx_irq 2: first->skb = skb eop_desc = tx_buffer->next_to_watch 3: ixgbe_tx_map read_barrier_depends() 4: wmb check adapter written status bit 5: first->next_to_watch = tx_desc napi_consume_skb(tx_buffer->skb ..); 6: writel(i, tx_ring->tail); The read_barrier_depends is insufficient to ensure that tx_buffer->skb does not get loaded prior to tx_buffer->next_to_watch, which then results in loading a stale skb pointer. This patch replaces the read_barrier_depends with smp_rmb to ensure loads are ordered with respect to the load of tx_buffer->next_to_watch. Signed-off-by: Brian King <brking(a)linux.vnet.ibm.com> Acked-by: Jesse Brandeburg <jesse.brandeburg(a)intel.com> Tested-by: Andrew Bowers <andrewx.bowers(a)intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher(a)intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c @@ -1192,7 +1192,7 @@ static bool ixgbe_clean_tx_irq(struct ix break; /* prevent any other reads prior to eop_desc */ - read_barrier_depends(); + smp_rmb(); /* if DD is not set pending work has not been completed */ if (!(eop_desc->wb.status & cpu_to_le32(IXGBE_TXD_STAT_DD))) Patches currently in stable-queue which might be from brking(a)linux.vnet.ibm.com are queue-4.14/i40evf-use-smp_rmb-rather-than-read_barrier_depends.patch queue-4.14/igb-use-smp_rmb-rather-than-read_barrier_depends.patch queue-4.14/ixgbevf-use-smp_rmb-rather-than-read_barrier_depends.patch queue-4.14/igbvf-use-smp_rmb-rather-than-read_barrier_depends.patch queue-4.14/fm10k-use-smp_rmb-rather-than-read_barrier_depends.patch queue-4.14/ixgbe-fix-skb-list-corruption-on-power-systems.patch queue-4.14/i40e-use-smp_rmb-rather-than-read_barrier_depends.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "igbvf: Use smp_rmb rather than read_barrier_depends" 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 igbvf: Use smp_rmb rather than read_barrier_depends 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: igbvf-use-smp_rmb-rather-than-read_barrier_depends.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 1e1f9ca546556e508d021545861f6b5fc75a95fe Mon Sep 17 00:00:00 2001 From: Brian King <brking(a)linux.vnet.ibm.com> Date: Fri, 17 Nov 2017 11:05:46 -0600 Subject: igbvf: Use smp_rmb rather than read_barrier_depends From: Brian King <brking(a)linux.vnet.ibm.com> commit 1e1f9ca546556e508d021545861f6b5fc75a95fe upstream. The original issue being fixed in this patch was seen with the ixgbe driver, but the same issue exists with igbvf as well, as the code is very similar. read_barrier_depends is not sufficient to ensure loads following it are not speculatively loaded out of order by the CPU, which can result in stale data being loaded, causing potential system crashes. Signed-off-by: Brian King <brking(a)linux.vnet.ibm.com> Acked-by: Jesse Brandeburg <jesse.brandeburg(a)intel.com> Tested-by: Aaron Brown <aaron.f.brown(a)intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher(a)intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/intel/igbvf/netdev.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/net/ethernet/intel/igbvf/netdev.c +++ b/drivers/net/ethernet/intel/igbvf/netdev.c @@ -810,7 +810,7 @@ static bool igbvf_clean_tx_irq(struct ig break; /* prevent any other reads prior to eop_desc */ - read_barrier_depends(); + smp_rmb(); /* if DD is not set pending work has not been completed */ if (!(eop_desc->wb.status & cpu_to_le32(E1000_TXD_STAT_DD))) Patches currently in stable-queue which might be from brking(a)linux.vnet.ibm.com are queue-4.14/i40evf-use-smp_rmb-rather-than-read_barrier_depends.patch queue-4.14/igb-use-smp_rmb-rather-than-read_barrier_depends.patch queue-4.14/ixgbevf-use-smp_rmb-rather-than-read_barrier_depends.patch queue-4.14/igbvf-use-smp_rmb-rather-than-read_barrier_depends.patch queue-4.14/fm10k-use-smp_rmb-rather-than-read_barrier_depends.patch queue-4.14/ixgbe-fix-skb-list-corruption-on-power-systems.patch queue-4.14/i40e-use-smp_rmb-rather-than-read_barrier_depends.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "igb: Use smp_rmb rather than read_barrier_depends" 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 igb: Use smp_rmb rather than read_barrier_depends 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: igb-use-smp_rmb-rather-than-read_barrier_depends.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 c4cb99185b4cc96c0a1c70104dc21ae14d7e7f28 Mon Sep 17 00:00:00 2001 From: Brian King <brking(a)linux.vnet.ibm.com> Date: Fri, 17 Nov 2017 11:05:47 -0600 Subject: igb: Use smp_rmb rather than read_barrier_depends From: Brian King <brking(a)linux.vnet.ibm.com> commit c4cb99185b4cc96c0a1c70104dc21ae14d7e7f28 upstream. The original issue being fixed in this patch was seen with the ixgbe driver, but the same issue exists with igb as well, as the code is very similar. read_barrier_depends is not sufficient to ensure loads following it are not speculatively loaded out of order by the CPU, which can result in stale data being loaded, causing potential system crashes. Signed-off-by: Brian King <brking(a)linux.vnet.ibm.com> Acked-by: Jesse Brandeburg <jesse.brandeburg(a)intel.com> Tested-by: Aaron Brown <aaron.f.brown(a)intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher(a)intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/intel/igb/igb_main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/net/ethernet/intel/igb/igb_main.c +++ b/drivers/net/ethernet/intel/igb/igb_main.c @@ -6970,7 +6970,7 @@ static bool igb_clean_tx_irq(struct igb_ break; /* prevent any other reads prior to eop_desc */ - read_barrier_depends(); + smp_rmb(); /* if DD is not set pending work has not been completed */ if (!(eop_desc->wb.status & cpu_to_le32(E1000_TXD_STAT_DD))) Patches currently in stable-queue which might be from brking(a)linux.vnet.ibm.com are queue-4.14/i40evf-use-smp_rmb-rather-than-read_barrier_depends.patch queue-4.14/igb-use-smp_rmb-rather-than-read_barrier_depends.patch queue-4.14/ixgbevf-use-smp_rmb-rather-than-read_barrier_depends.patch queue-4.14/igbvf-use-smp_rmb-rather-than-read_barrier_depends.patch queue-4.14/fm10k-use-smp_rmb-rather-than-read_barrier_depends.patch queue-4.14/ixgbe-fix-skb-list-corruption-on-power-systems.patch queue-4.14/i40e-use-smp_rmb-rather-than-read_barrier_depends.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "i40evf: Use smp_rmb rather than read_barrier_depends" 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 i40evf: Use smp_rmb rather than read_barrier_depends 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: i40evf-use-smp_rmb-rather-than-read_barrier_depends.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 f72271e2a0ae4277d53c4053f5eed8bb346ba38a Mon Sep 17 00:00:00 2001 From: Brian King <brking(a)linux.vnet.ibm.com> Date: Fri, 17 Nov 2017 11:05:49 -0600 Subject: i40evf: Use smp_rmb rather than read_barrier_depends From: Brian King <brking(a)linux.vnet.ibm.com> commit f72271e2a0ae4277d53c4053f5eed8bb346ba38a upstream. The original issue being fixed in this patch was seen with the ixgbe driver, but the same issue exists with i40evf as well, as the code is very similar. read_barrier_depends is not sufficient to ensure loads following it are not speculatively loaded out of order by the CPU, which can result in stale data being loaded, causing potential system crashes. Signed-off-by: Brian King <brking(a)linux.vnet.ibm.com> Acked-by: Jesse Brandeburg <jesse.brandeburg(a)intel.com> Tested-by: Andrew Bowers <andrewx.bowers(a)intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher(a)intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/intel/i40evf/i40e_txrx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/net/ethernet/intel/i40evf/i40e_txrx.c +++ b/drivers/net/ethernet/intel/i40evf/i40e_txrx.c @@ -179,7 +179,7 @@ static bool i40e_clean_tx_irq(struct i40 break; /* prevent any other reads prior to eop_desc */ - read_barrier_depends(); + smp_rmb(); i40e_trace(clean_tx_irq, tx_ring, tx_desc, tx_buf); /* if the descriptor isn't done, no work yet to do */ Patches currently in stable-queue which might be from brking(a)linux.vnet.ibm.com are queue-4.14/i40evf-use-smp_rmb-rather-than-read_barrier_depends.patch queue-4.14/igb-use-smp_rmb-rather-than-read_barrier_depends.patch queue-4.14/ixgbevf-use-smp_rmb-rather-than-read_barrier_depends.patch queue-4.14/igbvf-use-smp_rmb-rather-than-read_barrier_depends.patch queue-4.14/fm10k-use-smp_rmb-rather-than-read_barrier_depends.patch queue-4.14/ixgbe-fix-skb-list-corruption-on-power-systems.patch queue-4.14/i40e-use-smp_rmb-rather-than-read_barrier_depends.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "fm10k: Use smp_rmb rather than read_barrier_depends" 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 fm10k: Use smp_rmb rather than read_barrier_depends 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: fm10k-use-smp_rmb-rather-than-read_barrier_depends.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 7b8edcc685b5e2c3c37aa13dc50a88e84a5bfef8 Mon Sep 17 00:00:00 2001 From: Brian King <brking(a)linux.vnet.ibm.com> Date: Fri, 17 Nov 2017 11:05:48 -0600 Subject: fm10k: Use smp_rmb rather than read_barrier_depends From: Brian King <brking(a)linux.vnet.ibm.com> commit 7b8edcc685b5e2c3c37aa13dc50a88e84a5bfef8 upstream. The original issue being fixed in this patch was seen with the ixgbe driver, but the same issue exists with fm10k as well, as the code is very similar. read_barrier_depends is not sufficient to ensure loads following it are not speculatively loaded out of order by the CPU, which can result in stale data being loaded, causing potential system crashes. Signed-off-by: Brian King <brking(a)linux.vnet.ibm.com> Acked-by: Jesse Brandeburg <jesse.brandeburg(a)intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher(a)intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/intel/fm10k/fm10k_main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/net/ethernet/intel/fm10k/fm10k_main.c +++ b/drivers/net/ethernet/intel/fm10k/fm10k_main.c @@ -1229,7 +1229,7 @@ static bool fm10k_clean_tx_irq(struct fm break; /* prevent any other reads prior to eop_desc */ - read_barrier_depends(); + smp_rmb(); /* if DD is not set pending work has not been completed */ if (!(eop_desc->flags & FM10K_TXD_FLAG_DONE)) Patches currently in stable-queue which might be from brking(a)linux.vnet.ibm.com are queue-4.14/i40evf-use-smp_rmb-rather-than-read_barrier_depends.patch queue-4.14/igb-use-smp_rmb-rather-than-read_barrier_depends.patch queue-4.14/ixgbevf-use-smp_rmb-rather-than-read_barrier_depends.patch queue-4.14/igbvf-use-smp_rmb-rather-than-read_barrier_depends.patch queue-4.14/fm10k-use-smp_rmb-rather-than-read_barrier_depends.patch queue-4.14/ixgbe-fix-skb-list-corruption-on-power-systems.patch queue-4.14/i40e-use-smp_rmb-rather-than-read_barrier_depends.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "i40e: Use smp_rmb rather than read_barrier_depends" 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 i40e: Use smp_rmb rather than read_barrier_depends 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: i40e-use-smp_rmb-rather-than-read_barrier_depends.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 52c6912fde0133981ee50ba08808f257829c4c93 Mon Sep 17 00:00:00 2001 From: Brian King <brking(a)linux.vnet.ibm.com> Date: Fri, 17 Nov 2017 11:05:44 -0600 Subject: i40e: Use smp_rmb rather than read_barrier_depends From: Brian King <brking(a)linux.vnet.ibm.com> commit 52c6912fde0133981ee50ba08808f257829c4c93 upstream. The original issue being fixed in this patch was seen with the ixgbe driver, but the same issue exists with i40e as well, as the code is very similar. read_barrier_depends is not sufficient to ensure loads following it are not speculatively loaded out of order by the CPU, which can result in stale data being loaded, causing potential system crashes. Signed-off-by: Brian King <brking(a)linux.vnet.ibm.com> Acked-by: Jesse Brandeburg <jesse.brandeburg(a)intel.com> Tested-by: Andrew Bowers <andrewx.bowers(a)intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher(a)intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/intel/i40e/i40e_main.c | 2 +- drivers/net/ethernet/intel/i40e/i40e_txrx.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) --- a/drivers/net/ethernet/intel/i40e/i40e_main.c +++ b/drivers/net/ethernet/intel/i40e/i40e_main.c @@ -3760,7 +3760,7 @@ static bool i40e_clean_fdir_tx_irq(struc break; /* prevent any other reads prior to eop_desc */ - read_barrier_depends(); + smp_rmb(); /* if the descriptor isn't done, no work yet to do */ if (!(eop_desc->cmd_type_offset_bsz & --- a/drivers/net/ethernet/intel/i40e/i40e_txrx.c +++ b/drivers/net/ethernet/intel/i40e/i40e_txrx.c @@ -759,7 +759,7 @@ static bool i40e_clean_tx_irq(struct i40 break; /* prevent any other reads prior to eop_desc */ - read_barrier_depends(); + smp_rmb(); i40e_trace(clean_tx_irq, tx_ring, tx_desc, tx_buf); /* we have caught up to head, no work left to do */ Patches currently in stable-queue which might be from brking(a)linux.vnet.ibm.com are queue-4.14/i40evf-use-smp_rmb-rather-than-read_barrier_depends.patch queue-4.14/igb-use-smp_rmb-rather-than-read_barrier_depends.patch queue-4.14/ixgbevf-use-smp_rmb-rather-than-read_barrier_depends.patch queue-4.14/igbvf-use-smp_rmb-rather-than-read_barrier_depends.patch queue-4.14/fm10k-use-smp_rmb-rather-than-read_barrier_depends.patch queue-4.14/ixgbe-fix-skb-list-corruption-on-power-systems.patch queue-4.14/i40e-use-smp_rmb-rather-than-read_barrier_depends.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "[media] cx231xx-cards: fix NULL-deref on missing association descriptor" 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 [media] cx231xx-cards: fix NULL-deref on missing association descriptor 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: cx231xx-cards-fix-null-deref-on-missing-association-descriptor.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 6c3b047fa2d2286d5e438bcb470c7b1a49f415f6 Mon Sep 17 00:00:00 2001 From: Johan Hovold <johan(a)kernel.org> Date: Thu, 21 Sep 2017 05:40:18 -0300 Subject: [media] cx231xx-cards: fix NULL-deref on missing association descriptor From: Johan Hovold <johan(a)kernel.org> commit 6c3b047fa2d2286d5e438bcb470c7b1a49f415f6 upstream. Make sure to check that we actually have an Interface Association Descriptor before dereferencing it during probe to avoid dereferencing a NULL-pointer. Fixes: e0d3bafd0258 ("V4L/DVB (10954): Add cx231xx USB driver") Reported-by: Andrey Konovalov <andreyknvl(a)google.com> Signed-off-by: Johan Hovold <johan(a)kernel.org> Tested-by: Andrey Konovalov <andreyknvl(a)google.com> Signed-off-by: Hans Verkuil <hans.verkuil(a)cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab(a)osg.samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/media/usb/cx231xx/cx231xx-cards.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/media/usb/cx231xx/cx231xx-cards.c +++ b/drivers/media/usb/cx231xx/cx231xx-cards.c @@ -1684,7 +1684,7 @@ static int cx231xx_usb_probe(struct usb_ nr = dev->devno; assoc_desc = udev->actconfig->intf_assoc[0]; - if (assoc_desc->bFirstInterface != ifnum) { + if (!assoc_desc || assoc_desc->bFirstInterface != ifnum) { dev_err(d, "Not found matching IAD interface\n"); retval = -ENODEV; goto err_if; Patches currently in stable-queue which might be from johan(a)kernel.org are queue-4.14/cx231xx-cards-fix-null-deref-on-missing-association-descriptor.patch queue-4.14/serdev-fix-registration-of-second-slave.patch queue-4.14/clk-ti-dra7-atl-clock-fix-child-node-lookups.patch queue-4.14/irqchip-gic-v3-fix-ppi-partitions-lookup.patch queue-4.14/nfc-fix-device-allocation-error-return.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "powerpc/signal: Properly handle return value from uprobe_deny_signal()" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled powerpc/signal: Properly handle return value from uprobe_deny_signal() to the 3.18-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-signal-properly-handle-return-value-from-uprobe_deny_signal.patch and it can be found in the queue-3.18 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 46725b17f1c6c815a41429259b3f070c01e71bc1 Mon Sep 17 00:00:00 2001 From: "Naveen N. Rao" <naveen.n.rao(a)linux.vnet.ibm.com> Date: Thu, 31 Aug 2017 21:55:57 +0530 Subject: powerpc/signal: Properly handle return value from uprobe_deny_signal() From: Naveen N. Rao <naveen.n.rao(a)linux.vnet.ibm.com> commit 46725b17f1c6c815a41429259b3f070c01e71bc1 upstream. When a uprobe is installed on an instruction that we currently do not emulate, we copy the instruction into a xol buffer and single step that instruction. If that instruction generates a fault, we abort the single stepping before invoking the signal handler. Once the signal handler is done, the uprobe trap is hit again since the instruction is retried and the process repeats. We use uprobe_deny_signal() to detect if the xol instruction triggered a signal. If so, we clear TIF_SIGPENDING and set TIF_UPROBE so that the signal is not handled until after the single stepping is aborted. In this case, uprobe_deny_signal() returns true and get_signal() ends up returning 0. However, in do_signal(), we are not looking at the return value, but depending on ksig.sig for further action, all with an uninitialized ksig that is not touched in this scenario. Fix the same by initializing ksig.sig to 0. Fixes: 129b69df9c90 ("powerpc: Use get_signal() signal_setup_done()") Reported-by: Anton Blanchard <anton(a)samba.org> Signed-off-by: Naveen N. Rao <naveen.n.rao(a)linux.vnet.ibm.com> Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/powerpc/kernel/signal.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/powerpc/kernel/signal.c +++ b/arch/powerpc/kernel/signal.c @@ -102,7 +102,7 @@ static void check_syscall_restart(struct static void do_signal(struct pt_regs *regs) { sigset_t *oldset = sigmask_to_save(); - struct ksignal ksig; + struct ksignal ksig = { .sig = 0 }; int ret; int is32 = is_32bit_task(); Patches currently in stable-queue which might be from naveen.n.rao(a)linux.vnet.ibm.com are queue-3.18/powerpc-signal-properly-handle-return-value-from-uprobe_deny_signal.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "parisc: Fix validity check of pointer size argument in new CAS implementation" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled parisc: Fix validity check of pointer size argument in new CAS implementation to the 3.18-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: parisc-fix-validity-check-of-pointer-size-argument-in-new-cas-implementation.patch and it can be found in the queue-3.18 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 05f016d2ca7a4fab99d5d5472168506ddf95e74f Mon Sep 17 00:00:00 2001 From: John David Anglin <dave.anglin(a)bell.net> Date: Sat, 11 Nov 2017 17:11:16 -0500 Subject: parisc: Fix validity check of pointer size argument in new CAS implementation From: John David Anglin <dave.anglin(a)bell.net> commit 05f016d2ca7a4fab99d5d5472168506ddf95e74f upstream. As noted by Christoph Biedl, passing a pointer size of 4 in the new CAS implementation causes a kernel crash. The attached patch corrects the off by one error in the argument validity check. In reviewing the code, I noticed that we only perform word operations with the pointer size argument. The subi instruction intentionally uses a word condition on 64-bit kernels. Nullification was used instead of a cmpib instruction as the branch should never be taken. The shlw pseudo-operation generates a depw,z instruction and it clears the target before doing a shift left word deposit. Thus, we don't need to clip the upper 32 bits of this argument on 64-bit kernels. Tested with a gcc testsuite run with a 64-bit kernel. The gcc atomic code in libgcc is the only direct user of the new CAS implementation that I am aware of. Signed-off-by: John David Anglin <dave.anglin(a)bell.net> Signed-off-by: Helge Deller <deller(a)gmx.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/parisc/kernel/syscall.S | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) --- a/arch/parisc/kernel/syscall.S +++ b/arch/parisc/kernel/syscall.S @@ -688,15 +688,15 @@ cas_action: /* ELF32 Process entry path */ lws_compare_and_swap_2: #ifdef CONFIG_64BIT - /* Clip the input registers */ + /* Clip the input registers. We don't need to clip %r23 as we + only use it for word operations */ depdi 0, 31, 32, %r26 depdi 0, 31, 32, %r25 depdi 0, 31, 32, %r24 - depdi 0, 31, 32, %r23 #endif /* Check the validity of the size pointer */ - subi,>>= 4, %r23, %r0 + subi,>>= 3, %r23, %r0 b,n lws_exit_nosys /* Jump to the functions which will load the old and new values into Patches currently in stable-queue which might be from dave.anglin(a)bell.net are queue-3.18/parisc-fix-validity-check-of-pointer-size-argument-in-new-cas-implementation.patch

7 years, 5 months

1
0
0 0

[Linux-stable-mirror] Patch "media: v4l2-ctrl: Fix flags field on Control events" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled media: v4l2-ctrl: Fix flags field on Control events to the 3.18-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: media-v4l2-ctrl-fix-flags-field-on-control-events.patch and it can be found in the queue-3.18 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 9cac9d2fb2fe0e0cadacdb94415b3fe49e3f724f Mon Sep 17 00:00:00 2001 From: Ricardo Ribalda <ricardo.ribalda(a)gmail.com> Date: Tue, 17 Oct 2017 11:48:50 -0400 Subject: media: v4l2-ctrl: Fix flags field on Control events From: Ricardo Ribalda Delgado <ricardo.ribalda(a)gmail.com> commit 9cac9d2fb2fe0e0cadacdb94415b3fe49e3f724f upstream. VIDIOC_DQEVENT and VIDIOC_QUERY_EXT_CTRL should give the same output for the control flags field. This patch creates a new function user_flags(), that calculates the user exported flags value (which is different than the kernel internal flags structure). This function is then used by all the code that exports the internal flags to userspace. Reported-by: Dimitrios Katsaros <patcherwork(a)gmail.com> Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda(a)gmail.com> Signed-off-by: Hans Verkuil <hans.verkuil(a)cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/media/v4l2-core/v4l2-ctrls.c | 16 ++++++++++++---- 1 file changed, 12 insertions(+), 4 deletions(-) --- a/drivers/media/v4l2-core/v4l2-ctrls.c +++ b/drivers/media/v4l2-core/v4l2-ctrls.c @@ -1196,6 +1196,16 @@ void v4l2_ctrl_fill(u32 id, const char * } EXPORT_SYMBOL(v4l2_ctrl_fill); +static u32 user_flags(const struct v4l2_ctrl *ctrl) +{ + u32 flags = ctrl->flags; + + if (ctrl->is_ptr) + flags |= V4L2_CTRL_FLAG_HAS_PAYLOAD; + + return flags; +} + static void fill_event(struct v4l2_event *ev, struct v4l2_ctrl *ctrl, u32 changes) { memset(ev->reserved, 0, sizeof(ev->reserved)); @@ -1203,7 +1213,7 @@ static void fill_event(struct v4l2_event ev->id = ctrl->id; ev->u.ctrl.changes = changes; ev->u.ctrl.type = ctrl->type; - ev->u.ctrl.flags = ctrl->flags; + ev->u.ctrl.flags = user_flags(ctrl); if (ctrl->is_ptr) ev->u.ctrl.value64 = 0; else @@ -2540,10 +2550,8 @@ int v4l2_query_ext_ctrl(struct v4l2_ctrl else qc->id = ctrl->id; strlcpy(qc->name, ctrl->name, sizeof(qc->name)); - qc->flags = ctrl->flags; + qc->flags = user_flags(ctrl); qc->type = ctrl->type; - if (ctrl->is_ptr) - qc->flags |= V4L2_CTRL_FLAG_HAS_PAYLOAD; qc->elem_size = ctrl->elem_size; qc->elems = ctrl->elems; qc->nr_of_dims = ctrl->nr_of_dims; Patches currently in stable-queue which might be from ricardo.ribalda(a)gmail.com are queue-3.18/media-v4l2-ctrl-fix-flags-field-on-control-events.patch

7 years, 5 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror