Linux-stable-mirror

linux-stable-mirror@lists.linaro.org

340 participants
124248 discussions

Patch "led: core: Fix brightness setting when setting delay_off=0" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled led: core: Fix brightness setting when setting delay_off=0 to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: led-core-fix-brightness-setting-when-setting-delay_off-0.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Wed Feb 28 16:13:29 CET 2018 From: Matthieu CASTET <matthieu.castet(a)parrot.com> Date: Tue, 12 Dec 2017 11:10:44 +0100 Subject: led: core: Fix brightness setting when setting delay_off=0 From: Matthieu CASTET <matthieu.castet(a)parrot.com> [ Upstream commit 2b83ff96f51d0b039c4561b9f95c824d7bddb85c ] With the current code, the following sequence won't work : echo timer > trigger echo 0 > delay_off * at this point we call ** led_delay_off_store ** led_blink_set --- drivers/leds/led-core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/leds/led-core.c +++ b/drivers/leds/led-core.c @@ -186,7 +186,7 @@ void led_blink_set(struct led_classdev * unsigned long *delay_on, unsigned long *delay_off) { - del_timer_sync(&led_cdev->blink_timer); + led_stop_software_blink(led_cdev); led_cdev->flags &= ~LED_BLINK_ONESHOT; led_cdev->flags &= ~LED_BLINK_ONESHOT_STOP; Patches currently in stable-queue which might be from matthieu.castet(a)parrot.com are queue-4.9/led-core-fix-brightness-setting-when-setting-delay_off-0.patch

7 years, 10 months

Patch "ip6_tunnel: get the min mtu properly in ip6_tnl_xmit" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ip6_tunnel: get the min mtu properly in ip6_tnl_xmit to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: ip6_tunnel-get-the-min-mtu-properly-in-ip6_tnl_xmit.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 Wed Feb 28 16:13:29 CET 2018 From: Xin Long <lucien.xin(a)gmail.com> Date: Mon, 18 Dec 2017 14:26:21 +0800 Subject: ip6_tunnel: get the min mtu properly in ip6_tnl_xmit From: Xin Long <lucien.xin(a)gmail.com> [ Upstream commit c9fefa08190fc879fb2e681035d7774e0a8c5170 ] Now it's using IPV6_MIN_MTU as the min mtu in ip6_tnl_xmit, but IPV6_MIN_MTU actually only works when the inner packet is ipv6. With IPV6_MIN_MTU for ipv4 packets, the new pmtu for inner dst couldn't be set less than 1280. It would cause tx_err and the packet to be dropped when the outer dst pmtu is close to 1280. Jianlin found it by running ipv4 traffic with the topo: (client) gre6 <---> eth1 (route) eth2 <---> gre6 (server) After changing eth2 mtu to 1300, the performance became very low, or the connection was even broken. The issue also affects ip4ip6 and ip6ip6 tunnels. So if the inner packet is ipv4, 576 should be considered as the min mtu. Note that for ip4ip6 and ip6ip6 tunnels, the inner packet can only be ipv4 or ipv6, but for gre6 tunnel, it may also be ARP. This patch using 576 as the min mtu for non-ipv6 packet works for all those cases. Reported-by: Jianlin Shi <jishi(a)redhat.com> Signed-off-by: Xin Long <lucien.xin(a)gmail.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/ipv6/ip6_tunnel.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) --- a/net/ipv6/ip6_tunnel.c +++ b/net/ipv6/ip6_tunnel.c @@ -1127,8 +1127,13 @@ route_lookup: max_headroom += 8; mtu -= 8; } - if (mtu < IPV6_MIN_MTU) - mtu = IPV6_MIN_MTU; + if (skb->protocol == htons(ETH_P_IPV6)) { + if (mtu < IPV6_MIN_MTU) + mtu = IPV6_MIN_MTU; + } else if (mtu < 576) { + mtu = 576; + } + if (skb_dst(skb) && !t->parms.collect_md) skb_dst(skb)->ops->update_pmtu(skb_dst(skb), NULL, skb, mtu); if (skb->len - t->tun_hlen - eth_hlen > mtu && !skb_is_gso(skb)) { Patches currently in stable-queue which might be from lucien.xin(a)gmail.com are queue-4.9/ip6_tunnel-get-the-min-mtu-properly-in-ip6_tnl_xmit.patch

7 years, 10 months

Patch "IB/mlx5: Fix mlx5_ib_alloc_mr error flow" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled IB/mlx5: Fix mlx5_ib_alloc_mr error flow to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: ib-mlx5-fix-mlx5_ib_alloc_mr-error-flow.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Wed Feb 28 16:13:29 CET 2018 From: Nitzan Carmi <nitzanc(a)mellanox.com> Date: Tue, 26 Dec 2017 11:20:20 +0200 Subject: IB/mlx5: Fix mlx5_ib_alloc_mr error flow From: Nitzan Carmi <nitzanc(a)mellanox.com> [ Upstream commit 45e6ae7ef21b907dacb18da62d5787d74a31d860 ] ibmr.device is being set only after ib_alloc_mr() is (successfully) complete. Therefore, in case mlx5_core_create_mkey() return with error, the error flow calls mlx5_free_priv_descs() which uses ibmr.device (which doesn't exist yet), causing a NULL dereference oops. To fix this, the IB device should be set in the mr struct earlier stage (e.g. prior to calling mlx5_core_create_mkey()). Fixes: 8a187ee52b04 ("IB/mlx5: Support the new memory registration API") Signed-off-by: Max Gurtovoy <maxg(a)mellanox.com> Signed-off-by: Nitzan Carmi <nitzanc(a)mellanox.com> Signed-off-by: Leon Romanovsky <leon(a)kernel.org> Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/infiniband/hw/mlx5/mr.c | 1 + 1 file changed, 1 insertion(+) --- a/drivers/infiniband/hw/mlx5/mr.c +++ b/drivers/infiniband/hw/mlx5/mr.c @@ -1648,6 +1648,7 @@ struct ib_mr *mlx5_ib_alloc_mr(struct ib MLX5_SET(mkc, mkc, access_mode, mr->access_mode); MLX5_SET(mkc, mkc, umr_en, 1); + mr->ibmr.device = pd->device; err = mlx5_core_create_mkey(dev->mdev, &mr->mmkey, in, inlen); if (err) goto err_destroy_psv; Patches currently in stable-queue which might be from nitzanc(a)mellanox.com are queue-4.9/ib-mlx5-fix-mlx5_ib_alloc_mr-error-flow.patch queue-4.9/ib-mlx4-fix-mlx4_ib_alloc_mr-error-flow.patch

7 years, 10 months

Patch "IB/mlx4: Fix mlx4_ib_alloc_mr error flow" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled IB/mlx4: Fix mlx4_ib_alloc_mr error flow to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: ib-mlx4-fix-mlx4_ib_alloc_mr-error-flow.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Wed Feb 28 16:13:29 CET 2018 From: Leon Romanovsky <leonro(a)mellanox.com> Date: Sun, 31 Dec 2017 15:33:14 +0200 Subject: IB/mlx4: Fix mlx4_ib_alloc_mr error flow From: Leon Romanovsky <leonro(a)mellanox.com> [ Upstream commit 5a371cf87e145b86efd32007e46146e78c1eff6d ] ibmr.device is being set only after ib_alloc_mr() is successfully complete. Therefore, in case imlx4_mr_enable() returns with error, the error flow unwinder calls to mlx4_free_priv_pages(), which uses ibmr.device. Such usage causes to NULL dereference oops and to fix it, the IB device should be set in the mr struct earlier stage (e.g. prior to calling mlx4_free_priv_pages()). Fixes: 1b2cd0fc673c ("IB/mlx4: Support the new memory registration API") Signed-off-by: Nitzan Carmi <nitzanc(a)mellanox.com> Signed-off-by: Leon Romanovsky <leonro(a)mellanox.com> Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/infiniband/hw/mlx4/mr.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/infiniband/hw/mlx4/mr.c +++ b/drivers/infiniband/hw/mlx4/mr.c @@ -406,7 +406,6 @@ struct ib_mr *mlx4_ib_alloc_mr(struct ib goto err_free_mr; mr->max_pages = max_num_sg; - err = mlx4_mr_enable(dev->dev, &mr->mmr); if (err) goto err_free_pl; @@ -417,6 +416,7 @@ struct ib_mr *mlx4_ib_alloc_mr(struct ib return &mr->ibmr; err_free_pl: + mr->ibmr.device = pd->device; mlx4_free_priv_pages(mr); err_free_mr: (void) mlx4_mr_free(dev->dev, &mr->mmr); Patches currently in stable-queue which might be from leonro(a)mellanox.com are queue-4.9/ib-mlx4-fix-mlx4_ib_alloc_mr-error-flow.patch

7 years, 10 months

Patch "IB/ipoib: Fix race condition in neigh creation" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled IB/ipoib: Fix race condition in neigh creation to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: ib-ipoib-fix-race-condition-in-neigh-creation.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 Wed Feb 28 16:13:29 CET 2018 From: Erez Shitrit <erezsh(a)mellanox.com> Date: Sun, 31 Dec 2017 15:33:15 +0200 Subject: IB/ipoib: Fix race condition in neigh creation From: Erez Shitrit <erezsh(a)mellanox.com> [ Upstream commit 16ba3defb8bd01a9464ba4820a487f5b196b455b ] When using enhanced mode for IPoIB, two threads may execute xmit in parallel to two different TX queues while the target is the same. In this case, both of them will add the same neighbor to the path's neigh link list and we might see the following message: list_add double add: new=ffff88024767a348, prev=ffff88024767a348... WARNING: lib/list_debug.c:31__list_add_valid+0x4e/0x70 ipoib_start_xmit+0x477/0x680 [ib_ipoib] dev_hard_start_xmit+0xb9/0x3e0 sch_direct_xmit+0xf9/0x250 __qdisc_run+0x176/0x5d0 __dev_queue_xmit+0x1f5/0xb10 __dev_queue_xmit+0x55/0xb10 Analysis: Two SKB are scheduled to be transmitted from two cores. In ipoib_start_xmit, both gets NULL when calling ipoib_neigh_get. Two calls to neigh_add_path are made. One thread takes the spin-lock and calls ipoib_neigh_alloc which creates the neigh structure, then (after the __path_find) the neigh is added to the path's neigh link list. When the second thread enters the critical section it also calls ipoib_neigh_alloc but in this case it gets the already allocated ipoib_neigh structure, which is already linked to the path's neigh link list and adds it again to the list. Which beside of triggering the list, it creates a loop in the linked list. This loop leads to endless loop inside path_rec_completion. Solution: Check list_empty(&neigh->list) before adding to the list. Add a similar fix in "ipoib_multicast.c::ipoib_mcast_send" Fixes: b63b70d87741 ('IPoIB: Use a private hash table for path lookup in xmit path') Signed-off-by: Erez Shitrit <erezsh(a)mellanox.com> Reviewed-by: Alex Vesker <valex(a)mellanox.com> Signed-off-by: Leon Romanovsky <leon(a)kernel.org> Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/infiniband/ulp/ipoib/ipoib_main.c | 25 ++++++++++++++++++------- drivers/infiniband/ulp/ipoib/ipoib_multicast.c | 5 ++++- 2 files changed, 22 insertions(+), 8 deletions(-) --- a/drivers/infiniband/ulp/ipoib/ipoib_main.c +++ b/drivers/infiniband/ulp/ipoib/ipoib_main.c @@ -919,8 +919,8 @@ static int path_rec_start(struct net_dev return 0; } -static void neigh_add_path(struct sk_buff *skb, u8 *daddr, - struct net_device *dev) +static struct ipoib_neigh *neigh_add_path(struct sk_buff *skb, u8 *daddr, + struct net_device *dev) { struct ipoib_dev_priv *priv = netdev_priv(dev); struct ipoib_path *path; @@ -933,7 +933,15 @@ static void neigh_add_path(struct sk_buf spin_unlock_irqrestore(&priv->lock, flags); ++dev->stats.tx_dropped; dev_kfree_skb_any(skb); - return; + return NULL; + } + + /* To avoid race condition, make sure that the + * neigh will be added only once. + */ + if (unlikely(!list_empty(&neigh->list))) { + spin_unlock_irqrestore(&priv->lock, flags); + return neigh; } path = __path_find(dev, daddr + 4); @@ -971,7 +979,7 @@ static void neigh_add_path(struct sk_buf spin_unlock_irqrestore(&priv->lock, flags); ipoib_send(dev, skb, path->ah, IPOIB_QPN(daddr)); ipoib_neigh_put(neigh); - return; + return NULL; } } else { neigh->ah = NULL; @@ -988,7 +996,7 @@ static void neigh_add_path(struct sk_buf spin_unlock_irqrestore(&priv->lock, flags); ipoib_neigh_put(neigh); - return; + return NULL; err_path: ipoib_neigh_free(neigh); @@ -998,6 +1006,8 @@ err_drop: spin_unlock_irqrestore(&priv->lock, flags); ipoib_neigh_put(neigh); + + return NULL; } static void unicast_arp_send(struct sk_buff *skb, struct net_device *dev, @@ -1103,8 +1113,9 @@ static int ipoib_start_xmit(struct sk_bu case htons(ETH_P_TIPC): neigh = ipoib_neigh_get(dev, phdr->hwaddr); if (unlikely(!neigh)) { - neigh_add_path(skb, phdr->hwaddr, dev); - return NETDEV_TX_OK; + neigh = neigh_add_path(skb, phdr->hwaddr, dev); + if (likely(!neigh)) + return NETDEV_TX_OK; } break; case htons(ETH_P_ARP): --- a/drivers/infiniband/ulp/ipoib/ipoib_multicast.c +++ b/drivers/infiniband/ulp/ipoib/ipoib_multicast.c @@ -818,7 +818,10 @@ void ipoib_mcast_send(struct net_device spin_lock_irqsave(&priv->lock, flags); if (!neigh) { neigh = ipoib_neigh_alloc(daddr, dev); - if (neigh) { + /* Make sure that the neigh will be added only + * once to mcast list. + */ + if (neigh && list_empty(&neigh->list)) { kref_get(&mcast->ah->ref); neigh->ah = mcast->ah; list_add_tail(&neigh->list, &mcast->neigh_list); Patches currently in stable-queue which might be from erezsh(a)mellanox.com are queue-4.9/ib-ipoib-fix-race-condition-in-neigh-creation.patch

7 years, 10 months

Patch "i40e/i40evf: Account for frags split over multiple descriptors in check linearize" 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/i40evf: Account for frags split over multiple descriptors in check linearize 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-i40evf-account-for-frags-split-over-multiple-descriptors-in-check-linearize.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 Wed Feb 28 16:13:29 CET 2018 From: Alexander Duyck <alexander.h.duyck(a)intel.com> Date: Fri, 8 Dec 2017 10:55:04 -0800 Subject: i40e/i40evf: Account for frags split over multiple descriptors in check linearize From: Alexander Duyck <alexander.h.duyck(a)intel.com> [ Upstream commit 248de22e638f10bd5bfc7624a357f940f66ba137 ] The original code for __i40e_chk_linearize didn't take into account the fact that if a fragment is 16K in size or larger it has to be split over 2 descriptors and the smaller of those 2 descriptors will be on the trailing edge of the transmit. As a result we can get into situations where we didn't catch requests that could result in a Tx hang. This patch takes care of that by subtracting the length of all but the trailing edge of the stale fragment before we test for sum. By doing this we can guarantee that we have all cases covered, including the case of a fragment that spans multiple descriptors. We don't need to worry about checking the inner portions of this since 12K is the maximum aligned DMA size and that is larger than any MSS will ever be since the MTU limit for jumbos is something on the order of 9K. Signed-off-by: Alexander Duyck <alexander.h.duyck(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: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/intel/i40e/i40e_txrx.c | 26 +++++++++++++++++++++++--- drivers/net/ethernet/intel/i40evf/i40e_txrx.c | 26 +++++++++++++++++++++++--- 2 files changed, 46 insertions(+), 6 deletions(-) --- a/drivers/net/ethernet/intel/i40e/i40e_txrx.c +++ b/drivers/net/ethernet/intel/i40e/i40e_txrx.c @@ -2670,10 +2670,30 @@ bool __i40e_chk_linearize(struct sk_buff /* Walk through fragments adding latest fragment, testing it, and * then removing stale fragments from the sum. */ - stale = &skb_shinfo(skb)->frags[0]; - for (;;) { + for (stale = &skb_shinfo(skb)->frags[0];; stale++) { + int stale_size = skb_frag_size(stale); + sum += skb_frag_size(frag++); + /* The stale fragment may present us with a smaller + * descriptor than the actual fragment size. To account + * for that we need to remove all the data on the front and + * figure out what the remainder would be in the last + * descriptor associated with the fragment. + */ + if (stale_size > I40E_MAX_DATA_PER_TXD) { + int align_pad = -(stale->page_offset) & + (I40E_MAX_READ_REQ_SIZE - 1); + + sum -= align_pad; + stale_size -= align_pad; + + do { + sum -= I40E_MAX_DATA_PER_TXD_ALIGNED; + stale_size -= I40E_MAX_DATA_PER_TXD_ALIGNED; + } while (stale_size > I40E_MAX_DATA_PER_TXD); + } + /* if sum is negative we failed to make sufficient progress */ if (sum < 0) return true; @@ -2681,7 +2701,7 @@ bool __i40e_chk_linearize(struct sk_buff if (!nr_frags--) break; - sum -= skb_frag_size(stale++); + sum -= stale_size; } return false; --- a/drivers/net/ethernet/intel/i40evf/i40e_txrx.c +++ b/drivers/net/ethernet/intel/i40evf/i40e_txrx.c @@ -1872,10 +1872,30 @@ bool __i40evf_chk_linearize(struct sk_bu /* Walk through fragments adding latest fragment, testing it, and * then removing stale fragments from the sum. */ - stale = &skb_shinfo(skb)->frags[0]; - for (;;) { + for (stale = &skb_shinfo(skb)->frags[0];; stale++) { + int stale_size = skb_frag_size(stale); + sum += skb_frag_size(frag++); + /* The stale fragment may present us with a smaller + * descriptor than the actual fragment size. To account + * for that we need to remove all the data on the front and + * figure out what the remainder would be in the last + * descriptor associated with the fragment. + */ + if (stale_size > I40E_MAX_DATA_PER_TXD) { + int align_pad = -(stale->page_offset) & + (I40E_MAX_READ_REQ_SIZE - 1); + + sum -= align_pad; + stale_size -= align_pad; + + do { + sum -= I40E_MAX_DATA_PER_TXD_ALIGNED; + stale_size -= I40E_MAX_DATA_PER_TXD_ALIGNED; + } while (stale_size > I40E_MAX_DATA_PER_TXD); + } + /* if sum is negative we failed to make sufficient progress */ if (sum < 0) return true; @@ -1883,7 +1903,7 @@ bool __i40evf_chk_linearize(struct sk_bu if (!nr_frags--) break; - sum -= skb_frag_size(stale++); + sum -= stale_size; } return false; Patches currently in stable-queue which might be from alexander.h.duyck(a)intel.com are queue-4.9/i40e-i40evf-account-for-frags-split-over-multiple-descriptors-in-check-linearize.patch

7 years, 10 months

[GIT PULL] commits for Linux 4.9

by Sasha Levin

-----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 331b057d4f3ccf2290e6e651b5728db81e9249c6: Linux 4.9.80 (2018-02-03 17:05:43 +0100) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/sashal/linux-stable.git tags/for-greg-4.9-23022018 for you to fetch changes up to c7d6e7d081e1943667564c44312888076817af54: net: gianfar_ptp: move set_fipers() to spinlock protecting area (2018-02-03 12:53:00 -0500) - ---------------------------------------------------------------- for-greg-4.9-23022018 - ---------------------------------------------------------------- Abhijeet Kumar (1): ASoC: nau8825: fix issue that pop noise when start capture Al Viro (1): sget(): handle failures of register_shrinker() Albert Hsieh (1): mtd: nand: brcmnand: Zero bitflip is not an error Alexander Duyck (1): i40e/i40evf: Account for frags split over multiple descriptors in check linearize Alexander Kochetkov (1): net: arc_emac: fix arc_emac_rx() error paths Alexey Khoroshilov (1): net: phy: xgene: disable clk on error paths Aliaksei Karaliou (2): xfs: quota: fix missed destroy of qi_tree_lock xfs: quota: check result of register_shrinker() Andreas Platschek (1): dmaengine: fsl-edma: disable clks on all error paths Arnaldo Carvalho de Melo (1): x86/asm: Allow again using asm.h when building for the 'bpf' clang target Arnd Bergmann (1): ARM: dts: ls1021a: fix incorrect clock references Brendan McGrath (1): ipv6: icmp6: Allow icmp messages to be looped back Cathy Avery (1): scsi: storvsc: Fix scsi_cmd error assignments in storvsc_handle_error Christophe JAILLET (1): mdio-sun4i: Fix a memory leak Chunyan Zhang (1): ARM: 8731/1: Fix csum_partial_copy_from_user() stack mismatch Daniele Palmas (1): net: usb: qmi_wwan: add Telit ME910 PID 0x1101 support Eduardo Otubo (1): xen-netfront: enable device after manual module load Erez Shitrit (1): IB/ipoib: Fix race condition in neigh creation Felix Janda (1): uapi libc compat: add fallback for unsupported libcs Fredrik Hallenberg (1): net: stmmac: Fix TX timestamp calculation Gao Feng (1): macvlan: Fix one possible double free Guenter Roeck (1): genirq: Guard handle_bad_irq log messages Guilherme G. Piccoli (1): bnx2x: Improve reliability in case of nested PCI errors Hao Chen (1): nl80211: Check for the required netlink attribute presence James Hogan (1): lib/mpi: Fix umul_ppmm() for MIPS64r6 Jia-Ju Bai (1): mac80211_hwsim: Fix a possible sleep-in-atomic bug in hwsim_get_radio_nl Johannes Berg (1): mac80211: mesh: drop frames appearing to be from us Karol Herbst (1): drm/nouveau/pci: do a msi rearm on init Keith Busch (1): nvme: check hw sectors before setting chunk sectors Leon Romanovsky (1): IB/mlx4: Fix mlx4_ib_alloc_mr error flow Luu An Phu (1): can: flex_can: Correct the checking for frame length in flexcan_start_xmit() Marcelo Ricardo Leitner (1): sctp: make use of pre-calculated len Matthieu CASTET (1): led: core: Fix brightness setting when setting delay_off=0 Nitzan Carmi (1): IB/mlx5: Fix mlx5_ib_alloc_mr error flow Radu Pirea (1): spi: atmel: fixed spin_lock usage inside atmel_spi_remove Ross Lagerwall (2): xen/gntdev: Fix off-by-one error when unmapping with holes xen/gntdev: Fix partial gntdev_mmap() cleanup SZ Lin (林上智) (1): NET: usb: qmi_wwan: add support for YUGA CLM920-NC5 PID 0x9625 Sascha Hauer (1): mtd: nand: gpmi: Fix failure when a erased page has a bitflip at BBM Sean Wang (1): net: mediatek: setup proper state for disabled GMAC on the default Sergei Shtylyov (1): SolutionEngine771x: fix Ether platform data Siva Reddy Kallam (2): tg3: Add workaround to restrict 5762 MRRS to 2048 tg3: Enable PHY reset in MTU change path for 5720 Stefan Haberland (1): s390/dasd: fix wrongly assigned configuration data Tetsuo Handa (1): mm,vmscan: Make unregister_shrinker() no-op if register_shrinker() failed. Tommi Rantala (2): tipc: error path leak fixes in tipc_enable_bearer() tipc: fix tipc_mon_delete() oops in tipc_enable_bearer() error path Tushar Dave (1): e1000: fix disabling already-disabled warning Venkat Duvvuru (1): bnxt_en: Fix the 'Invalid VF' id check in bnxt_vf_ndo_prep routine. Xin Long (1): ip6_tunnel: get the min mtu properly in ip6_tnl_xmit Xiongwei Song (1): drm/ttm: check the return value of kzalloc Yangbo Lu (1): net: gianfar_ptp: move set_fipers() to spinlock protecting area arch/arm/boot/dts/ls1021a-qds.dts | 2 +- arch/arm/boot/dts/ls1021a-twr.dts | 2 +- arch/arm/lib/csumpartialcopyuser.S | 4 ++ arch/sh/boards/mach-se/770x/setup.c | 10 +++- arch/x86/include/asm/asm.h | 2 + drivers/dma/fsl-edma.c | 28 +++++------ drivers/gpu/drm/nouveau/nvkm/subdev/pci/base.c | 7 +++ drivers/gpu/drm/ttm/ttm_page_alloc.c | 2 + drivers/infiniband/hw/mlx4/mr.c | 2 +- drivers/infiniband/hw/mlx5/mr.c | 1 + drivers/infiniband/ulp/ipoib/ipoib_main.c | 25 +++++++--- drivers/infiniband/ulp/ipoib/ipoib_multicast.c | 5 +- drivers/leds/led-core.c | 2 +- drivers/mtd/nand/brcmnand/brcmnand.c | 2 +- drivers/mtd/nand/gpmi-nand/gpmi-nand.c | 6 +-- drivers/net/can/flexcan.c | 2 +- drivers/net/ethernet/arc/emac_main.c | 53 ++++++++++++--------- drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c | 4 +- drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 14 +++++- drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c | 2 +- drivers/net/ethernet/broadcom/tg3.c | 13 ++++- drivers/net/ethernet/broadcom/tg3.h | 4 ++ drivers/net/ethernet/freescale/gianfar_ptp.c | 3 +- drivers/net/ethernet/intel/e1000/e1000.h | 3 +- drivers/net/ethernet/intel/e1000/e1000_main.c | 27 +++++++++-- drivers/net/ethernet/intel/i40e/i40e_txrx.c | 26 ++++++++-- drivers/net/ethernet/intel/i40evf/i40e_txrx.c | 26 ++++++++-- drivers/net/ethernet/mediatek/mtk_eth_soc.c | 11 +++-- .../net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c | 6 ++- drivers/net/macvlan.c | 7 ++- drivers/net/phy/mdio-sun4i.c | 6 ++- drivers/net/phy/mdio-xgene.c | 21 ++++++--- drivers/net/usb/qmi_wwan.c | 2 + drivers/net/wireless/mac80211_hwsim.c | 2 +- drivers/net/xen-netfront.c | 1 + drivers/nvme/host/core.c | 3 +- drivers/s390/block/dasd_3990_erp.c | 10 ++++ drivers/scsi/storvsc_drv.c | 3 +- drivers/spi/spi-atmel.c | 2 +- drivers/xen/gntdev.c | 8 ++-- fs/super.c | 6 ++- fs/xfs/xfs_qm.c | 46 +++++++++++------- include/uapi/linux/libc-compat.h | 55 +++++++++++++++++++++- kernel/irq/debug.h | 5 ++ lib/mpi/longlong.h | 18 ++++++- mm/vmscan.c | 3 ++ net/ipv6/ip6_tunnel.c | 9 +++- net/ipv6/route.c | 1 + net/mac80211/rx.c | 2 + net/sctp/socket.c | 16 ++++--- net/tipc/bearer.c | 5 +- net/tipc/monitor.c | 6 ++- net/wireless/nl80211.c | 3 +- sound/soc/codecs/nau8825.c | 1 + 54 files changed, 407 insertions(+), 128 deletions(-) -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJakgpcAAoJEN6mb/eXdyzcYeQP/2MlZj2rqiRlWcjceq3kn899 1yFsScoCH/7HqJbOP3gyfT4S+SbXjs55vCYNbKynNeXUFqG7mPk/h1VQxo06qiao oBdhegFByKYr3HkY4BJopPssmofecHi2JT7e1P1Ow+eqIxCQECl5txjkb/oa0t+1 NMbCju60uQlgPtUc/m5qCICzzERKecJPGb5v9xrZ69bEXgfv7+6v9V6F2PsC0SRR tCkuRrQuOyI7y9S8UcL0ECb98mTVVwqNs48VG1yGpt5mSyopgDprdJJvlw0jOzhk 7XtX8eTtxkEt8rs4RSH+aSQxwmFVVWpbGo3fmZLyhIeEQVBLiXcjtT1sRvrPQyXM n68Oy06s8QOXrtRTGE1w3DpfRkB0d2LUeEX7oqpuoOG/ypqunjmHn1E5StDXEH7S xx7fXMkZWplCnFADRWKkAIRkutc1ISbnOI9u+79eQPQu55KBeW3HxX0jxcgQFUb+ qIhzUQM/r94P93xvGSOVMArt8Q+a1RIG1QnH+LdMRCQsQon6QIlokdBpRsQtVHUX vosYNk4kWChL2fF9C8jat0QUZzaqtqiyCKZK2wCDMQPUx7ERyL3wFLkWK/c/LSYk V22R6dGvfRyM+ifug00dZBuP4MTlLFhuQ+Q04afiqC9J1IjM6cXFDbucYmWLrwAr ktgD88//umVLWN6qsizR =Un5c -----END PGP SIGNATURE-----

7 years, 10 months

Patch "genirq: Guard handle_bad_irq log messages" 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 genirq: Guard handle_bad_irq log messages 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: genirq-guard-handle_bad_irq-log-messages.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 Wed Feb 28 16:13:29 CET 2018 From: Guenter Roeck <linux(a)roeck-us.net> Date: Sat, 2 Dec 2017 09:13:04 -0800 Subject: genirq: Guard handle_bad_irq log messages From: Guenter Roeck <linux(a)roeck-us.net> [ Upstream commit 11bca0a83f83f6093d816295668e74ef24595944 ] An interrupt storm on a bad interrupt will cause the kernel log to be clogged. [ 60.089234] ->handle_irq(): ffffffffbe2f803f, [ 60.090455] 0xffffffffbf2af380 [ 60.090510] handle_bad_irq+0x0/0x2e5 [ 60.090522] ->irq_data.chip(): ffffffffbf2af380, [ 60.090553] IRQ_NOPROBE set [ 60.090584] ->handle_irq(): ffffffffbe2f803f, [ 60.090590] handle_bad_irq+0x0/0x2e5 [ 60.090596] ->irq_data.chip(): ffffffffbf2af380, [ 60.090602] 0xffffffffbf2af380 [ 60.090608] ->action(): (null) [ 60.090779] handle_bad_irq+0x0/0x2e5 This was seen when running an upstream kernel on Acer Chromebook R11. The system was unstable as result. Guard the log message with __printk_ratelimit to reduce the impact. This won't prevent the interrupt storm from happening, but at least the system remains stable. Signed-off-by: Guenter Roeck <linux(a)roeck-us.net> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Cc: Dmitry Torokhov <dtor(a)chromium.org> Cc: Joe Perches <joe(a)perches.com> Cc: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> Cc: Mika Westerberg <mika.westerberg(a)linux.intel.com> Link: https://bugzilla.kernel.org/show_bug.cgi?id=197953 Link: https://lkml.kernel.org/r/1512234784-21038-1-git-send-email-linux@roeck-us.… Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- kernel/irq/debug.h | 5 +++++ 1 file changed, 5 insertions(+) --- a/kernel/irq/debug.h +++ b/kernel/irq/debug.h @@ -11,6 +11,11 @@ static inline void print_irq_desc(unsigned int irq, struct irq_desc *desc) { + static DEFINE_RATELIMIT_STATE(ratelimit, 5 * HZ, 5); + + if (!__ratelimit(&ratelimit)) + return; + printk("irq %d, desc: %p, depth: %d, count: %d, unhandled: %d\n", irq, desc, desc->depth, desc->irq_count, desc->irqs_unhandled); printk("->handle_irq(): %p, ", desc->handle_irq); Patches currently in stable-queue which might be from linux(a)roeck-us.net are queue-4.9/genirq-guard-handle_bad_irq-log-messages.patch

7 years, 10 months

Patch "e1000: fix disabling already-disabled warning" 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 e1000: fix disabling already-disabled warning 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: e1000-fix-disabling-already-disabled-warning.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 Wed Feb 28 16:13:29 CET 2018 From: Tushar Dave <tushar.n.dave(a)oracle.com> Date: Wed, 6 Dec 2017 02:26:29 +0530 Subject: e1000: fix disabling already-disabled warning From: Tushar Dave <tushar.n.dave(a)oracle.com> [ Upstream commit 0b76aae741abb9d16d2c0e67f8b1e766576f897d ] This patch adds check so that driver does not disable already disabled device. [ 44.637743] advantechwdt: Unexpected close, not stopping watchdog! [ 44.997548] input: ImExPS/2 Generic Explorer Mouse as /devices/platform/i8042/serio1/input/input6 [ 45.013419] e1000 0000:00:03.0: disabling already-disabled device [ 45.013447] ------------[ cut here ]------------ [ 45.014868] WARNING: CPU: 1 PID: 71 at drivers/pci/pci.c:1641 pci_disable_device+0xa1/0x105: pci_disable_device at drivers/pci/pci.c:1640 [ 45.016171] CPU: 1 PID: 71 Comm: rcu_perf_shutdo Not tainted 4.14.0-01330-g3c07399 #1 [ 45.017197] task: ffff88011bee9e40 task.stack: ffffc90000860000 [ 45.017987] RIP: 0010:pci_disable_device+0xa1/0x105: pci_disable_device at drivers/pci/pci.c:1640 [ 45.018603] RSP: 0000:ffffc90000863e30 EFLAGS: 00010286 [ 45.019282] RAX: 0000000000000035 RBX: ffff88013a230008 RCX: 0000000000000000 [ 45.020182] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000203 [ 45.021084] RBP: ffff88013a3f31e8 R08: 0000000000000001 R09: 0000000000000000 [ 45.021986] R10: ffffffff827ec29c R11: 0000000000000002 R12: 0000000000000001 [ 45.022946] R13: ffff88013a230008 R14: ffff880117802b20 R15: ffffc90000863e8f [ 45.023842] FS: 0000000000000000(0000) GS:ffff88013fd00000(0000) knlGS:0000000000000000 [ 45.024863] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 45.025583] CR2: ffffc900006d4000 CR3: 000000000220f000 CR4: 00000000000006a0 [ 45.026478] Call Trace: [ 45.026811] __e1000_shutdown+0x1d4/0x1e2: __e1000_shutdown at drivers/net/ethernet/intel/e1000/e1000_main.c:5162 [ 45.027344] ? rcu_perf_cleanup+0x2a1/0x2a1: rcu_perf_shutdown at kernel/rcu/rcuperf.c:627 [ 45.027883] e1000_shutdown+0x14/0x3a: e1000_shutdown at drivers/net/ethernet/intel/e1000/e1000_main.c:5235 [ 45.028351] device_shutdown+0x110/0x1aa: device_shutdown at drivers/base/core.c:2807 [ 45.028858] kernel_power_off+0x31/0x64: kernel_power_off at kernel/reboot.c:260 [ 45.029343] rcu_perf_shutdown+0x9b/0xa7: rcu_perf_shutdown at kernel/rcu/rcuperf.c:637 [ 45.029852] ? __wake_up_common_lock+0xa2/0xa2: autoremove_wake_function at kernel/sched/wait.c:376 [ 45.030414] kthread+0x126/0x12e: kthread at kernel/kthread.c:233 [ 45.030834] ? __kthread_bind_mask+0x8e/0x8e: kthread at kernel/kthread.c:190 [ 45.031399] ? ret_from_fork+0x1f/0x30: ret_from_fork at arch/x86/entry/entry_64.S:443 [ 45.031883] ? kernel_init+0xa/0xf5: kernel_init at init/main.c:997 [ 45.032325] ret_from_fork+0x1f/0x30: ret_from_fork at arch/x86/entry/entry_64.S:443 [ 45.032777] Code: 00 48 85 ed 75 07 48 8b ab a8 00 00 00 48 8d bb 98 00 00 00 e8 aa d1 11 00 48 89 ea 48 89 c6 48 c7 c7 d8 e4 0b 82 e8 55 7d da ff <0f> ff b9 01 00 00 00 31 d2 be 01 00 00 00 48 c7 c7 f0 b1 61 82 [ 45.035222] ---[ end trace c257137b1b1976ef ]--- [ 45.037838] ACPI: Preparing to enter system sleep state S5 Signed-off-by: Tushar Dave <tushar.n.dave(a)oracle.com> Tested-by: Fengguang Wu <fengguang.wu(a)intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher(a)intel.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/intel/e1000/e1000.h | 3 +- drivers/net/ethernet/intel/e1000/e1000_main.c | 27 +++++++++++++++++++++----- 2 files changed, 24 insertions(+), 6 deletions(-) --- a/drivers/net/ethernet/intel/e1000/e1000.h +++ b/drivers/net/ethernet/intel/e1000/e1000.h @@ -331,7 +331,8 @@ struct e1000_adapter { enum e1000_state_t { __E1000_TESTING, __E1000_RESETTING, - __E1000_DOWN + __E1000_DOWN, + __E1000_DISABLED }; #undef pr_fmt --- a/drivers/net/ethernet/intel/e1000/e1000_main.c +++ b/drivers/net/ethernet/intel/e1000/e1000_main.c @@ -940,7 +940,7 @@ static int e1000_init_hw_struct(struct e static int e1000_probe(struct pci_dev *pdev, const struct pci_device_id *ent) { struct net_device *netdev; - struct e1000_adapter *adapter; + struct e1000_adapter *adapter = NULL; struct e1000_hw *hw; static int cards_found; @@ -950,6 +950,7 @@ static int e1000_probe(struct pci_dev *p u16 tmp = 0; u16 eeprom_apme_mask = E1000_EEPROM_APME; int bars, need_ioport; + bool disable_dev = false; /* do not allocate ioport bars when not needed */ need_ioport = e1000_is_need_ioport(pdev); @@ -1250,11 +1251,13 @@ err_mdio_ioremap: iounmap(hw->ce4100_gbe_mdio_base_virt); iounmap(hw->hw_addr); err_ioremap: + disable_dev = !test_and_set_bit(__E1000_DISABLED, &adapter->flags); free_netdev(netdev); err_alloc_etherdev: pci_release_selected_regions(pdev, bars); err_pci_reg: - pci_disable_device(pdev); + if (!adapter || disable_dev) + pci_disable_device(pdev); return err; } @@ -1272,6 +1275,7 @@ static void e1000_remove(struct pci_dev struct net_device *netdev = pci_get_drvdata(pdev); struct e1000_adapter *adapter = netdev_priv(netdev); struct e1000_hw *hw = &adapter->hw; + bool disable_dev; e1000_down_and_stop(adapter); e1000_release_manageability(adapter); @@ -1290,9 +1294,11 @@ static void e1000_remove(struct pci_dev iounmap(hw->flash_address); pci_release_selected_regions(pdev, adapter->bars); + disable_dev = !test_and_set_bit(__E1000_DISABLED, &adapter->flags); free_netdev(netdev); - pci_disable_device(pdev); + if (disable_dev) + pci_disable_device(pdev); } /** @@ -5166,7 +5172,8 @@ static int __e1000_shutdown(struct pci_d if (netif_running(netdev)) e1000_free_irq(adapter); - pci_disable_device(pdev); + if (!test_and_set_bit(__E1000_DISABLED, &adapter->flags)) + pci_disable_device(pdev); return 0; } @@ -5210,6 +5217,10 @@ static int e1000_resume(struct pci_dev * pr_err("Cannot enable PCI device from suspend\n"); return err; } + + /* flush memory to make sure state is correct */ + smp_mb__before_atomic(); + clear_bit(__E1000_DISABLED, &adapter->flags); pci_set_master(pdev); pci_enable_wake(pdev, PCI_D3hot, 0); @@ -5284,7 +5295,9 @@ static pci_ers_result_t e1000_io_error_d if (netif_running(netdev)) e1000_down(adapter); - pci_disable_device(pdev); + + if (!test_and_set_bit(__E1000_DISABLED, &adapter->flags)) + pci_disable_device(pdev); /* Request a slot slot reset. */ return PCI_ERS_RESULT_NEED_RESET; @@ -5312,6 +5325,10 @@ static pci_ers_result_t e1000_io_slot_re pr_err("Cannot re-enable PCI device after reset.\n"); return PCI_ERS_RESULT_DISCONNECT; } + + /* flush memory to make sure state is correct */ + smp_mb__before_atomic(); + clear_bit(__E1000_DISABLED, &adapter->flags); pci_set_master(pdev); pci_enable_wake(pdev, PCI_D3hot, 0); Patches currently in stable-queue which might be from tushar.n.dave(a)oracle.com are queue-4.9/e1000-fix-disabling-already-disabled-warning.patch

7 years, 10 months

Patch "drm/ttm: check the return value of kzalloc" 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/ttm: check the return value of kzalloc 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-ttm-check-the-return-value-of-kzalloc.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 Wed Feb 28 16:13:29 CET 2018 From: Xiongwei Song <sxwjean(a)gmail.com> Date: Tue, 2 Jan 2018 21:24:55 +0800 Subject: drm/ttm: check the return value of kzalloc From: Xiongwei Song <sxwjean(a)gmail.com> [ Upstream commit 19d859a7205bc59ffc38303eb25ae394f61d21dc ] In the function ttm_page_alloc_init, kzalloc call is made for variable _manager, we need to check its return value, it may return NULL. Signed-off-by: Xiongwei Song <sxwjean(a)gmail.com> Reviewed-by: Christian König <christian.koenig(a)amd.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/gpu/drm/ttm/ttm_page_alloc.c | 2 ++ 1 file changed, 2 insertions(+) --- a/drivers/gpu/drm/ttm/ttm_page_alloc.c +++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c @@ -818,6 +818,8 @@ int ttm_page_alloc_init(struct ttm_mem_g pr_info("Initializing pool allocator\n"); _manager = kzalloc(sizeof(*_manager), GFP_KERNEL); + if (!_manager) + return -ENOMEM; ttm_page_pool_init_locked(&_manager->wc_pool, GFP_HIGHUSER, "wc"); Patches currently in stable-queue which might be from sxwjean(a)gmail.com are queue-4.9/drm-ttm-check-the-return-value-of-kzalloc.patch

7 years, 10 months

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror