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

Patch "Input: xen-kbdfront - do not advertise multi-touch pressure support" 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 Input: xen-kbdfront - do not advertise multi-touch pressure support 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: input-xen-kbdfront-do-not-advertise-multi-touch-pressure-support.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Wed Feb 28 16:23:28 CET 2018 From: Oleksandr Andrushchenko <oleksandr_andrushchenko(a)epam.com> Date: Tue, 2 Jan 2018 09:39:25 -0800 Subject: Input: xen-kbdfront - do not advertise multi-touch pressure support From: Oleksandr Andrushchenko <oleksandr_andrushchenko(a)epam.com> [ Upstream commit 02a0d9216d4daf6a58d88642bd2da2c78c327552 ] Some user-space applications expect multi-touch pressure on contact to be reported if it is advertised in device properties. Otherwise, such applications may treat reports not as actual touches, but hovering. Currently this is only advertised, but not reported. Fix this by not advertising that ABS_MT_PRESSURE is supported. Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko(a)epam.com> Signed-off-by: Andrii Chepurnyi <andrii_chepurnyi(a)epam.com> Patchwork-Id: 10140017 Signed-off-by: Dmitry Torokhov <dmitry.torokhov(a)gmail.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/input/misc/xen-kbdfront.c | 2 -- 1 file changed, 2 deletions(-) --- a/drivers/input/misc/xen-kbdfront.c +++ b/drivers/input/misc/xen-kbdfront.c @@ -326,8 +326,6 @@ static int xenkbd_probe(struct xenbus_de 0, width, 0, 0); input_set_abs_params(mtouch, ABS_MT_POSITION_Y, 0, height, 0, 0); - input_set_abs_params(mtouch, ABS_MT_PRESSURE, - 0, 255, 0, 0); ret = input_mt_init_slots(mtouch, num_cont, INPUT_MT_DIRECT); if (ret) { Patches currently in stable-queue which might be from oleksandr_andrushchenko(a)epam.com are queue-4.14/input-xen-kbdfront-do-not-advertise-multi-touch-pressure-support.patch

7 years, 4 months

1
0
0 0

Patch "IB/mlx5: Fix mlx5_ib_alloc_mr error flow" 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 IB/mlx5: Fix mlx5_ib_alloc_mr error flow 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: ib-mlx5-fix-mlx5_ib_alloc_mr-error-flow.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Wed Feb 28 16:23:28 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)verizon.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 @@ -1637,6 +1637,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.14/ib-mlx5-fix-mlx5_ib_alloc_mr-error-flow.patch queue-4.14/ib-mlx4-fix-mlx4_ib_alloc_mr-error-flow.patch

7 years, 4 months

1
0
0 0

Patch "IB/mlx4: Fix mlx4_ib_alloc_mr error flow" 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 IB/mlx4: Fix mlx4_ib_alloc_mr error flow 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: ib-mlx4-fix-mlx4_ib_alloc_mr-error-flow.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Wed Feb 28 16:23:28 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)verizon.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.14/ib-mlx4-fix-mlx4_ib_alloc_mr-error-flow.patch queue-4.14/rdma-netlink-fix-locking-around-__ib_get_device_by_index.patch

7 years, 4 months

1
0
0 0

Patch "IB/ipoib: Fix race condition in neigh creation" 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 IB/ipoib: Fix race condition in neigh creation 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: ib-ipoib-fix-race-condition-in-neigh-creation.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Wed Feb 28 16:23:28 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)verizon.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 @@ -903,8 +903,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 = ipoib_priv(dev); struct rdma_netdev *rn = netdev_priv(dev); @@ -918,7 +918,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); @@ -957,7 +965,7 @@ static void neigh_add_path(struct sk_buf path->ah->last_send = rn->send(dev, skb, path->ah->ah, IPOIB_QPN(daddr)); ipoib_neigh_put(neigh); - return; + return NULL; } } else { neigh->ah = NULL; @@ -974,7 +982,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); @@ -984,6 +992,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, @@ -1092,8 +1102,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 @@ -816,7 +816,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.14/ib-ipoib-fix-race-condition-in-neigh-creation.patch

7 years, 4 months

1
0
0 0

Patch "ia64, sched/cputime: Fix build error if CONFIG_VIRT_CPU_ACCOUNTING_NATIVE=y" 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 ia64, sched/cputime: Fix build error if CONFIG_VIRT_CPU_ACCOUNTING_NATIVE=y 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: ia64-sched-cputime-fix-build-error-if-config_virt_cpu_accounting_native-y.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Wed Feb 28 16:23:28 CET 2018 From: Valentin Ilie <valentin.ilie(a)gmail.com> Date: Fri, 5 Jan 2018 23:12:59 +0000 Subject: ia64, sched/cputime: Fix build error if CONFIG_VIRT_CPU_ACCOUNTING_NATIVE=y From: Valentin Ilie <valentin.ilie(a)gmail.com> [ Upstream commit 7729bebc619307a0233c86f8585a4bf3eadc7ce4 ] Remove the extra parenthesis. This bug was introduced by: e2339a4caa5e: ("ia64: Convert vtime to use nsec units directly") Signed-off-by: Valentin Ilie <valentin.ilie(a)gmail.com> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: fenghua.yu(a)intel.com Cc: linux-ia64(a)vger.kernel.org Cc: tony.luck(a)intel.com Link: http://lkml.kernel.org/r/1515193979-24873-1-git-send-email-valentin.ilie@gm… Signed-off-by: Ingo Molnar <mingo(a)kernel.org> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/ia64/kernel/time.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/ia64/kernel/time.c +++ b/arch/ia64/kernel/time.c @@ -88,7 +88,7 @@ void vtime_flush(struct task_struct *tsk } if (ti->softirq_time) { - delta = cycle_to_nsec(ti->softirq_time)); + delta = cycle_to_nsec(ti->softirq_time); account_system_index_time(tsk, delta, CPUTIME_SOFTIRQ); } Patches currently in stable-queue which might be from valentin.ilie(a)gmail.com are queue-4.14/ia64-sched-cputime-fix-build-error-if-config_virt_cpu_accounting_native-y.patch

7 years, 4 months

1
0
0 0

Patch "i915: Reject CCS modifiers for pipe C on Geminilake" 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 i915: Reject CCS modifiers for pipe C on Geminilake 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: i915-reject-ccs-modifiers-for-pipe-c-on-geminilake.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Wed Feb 28 16:23:28 CET 2018 From: Gabriel Krisman Bertazi <krisman(a)collabora.co.uk> Date: Tue, 19 Dec 2017 22:24:10 -0200 Subject: i915: Reject CCS modifiers for pipe C on Geminilake From: Gabriel Krisman Bertazi <krisman(a)collabora.co.uk> [ Upstream commit 8bc0d7ac934b6f2d0dc8f38a3104d281c9db1e98 ] Current code advertises (on the modifiers blob property) support for CCS modifier for pipe C on GLK, only to reject it later when validating the request before the atomic commit. This fixes the tests igt@kms_ccs@pipe-c-*, which should skip on GLK for pipe C (see bug 104096). A relevant discussion is archived at: https://lists.freedesktop.org/archives/intel-gfx/2017-December/150646.html Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104096 Signed-off-by: Gabriel Krisman Bertazi <krisman(a)collabora.co.uk> Cc: Ben Widawsky <ben(a)bwidawsk.net> Reviewed-by: Ben Widawsky <ben(a)bwidawsk.net> Signed-off-by: Rodrigo Vivi <rodrigo.vivi(a)intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171220002410.5604-1-krisman… (cherry picked from commit f0cbd8bd877f3d8c5b80a6b1add9ca9010d7f9d8) Signed-off-by: Jani Nikula <jani.nikula(a)intel.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/gpu/drm/i915/intel_display.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -13240,7 +13240,7 @@ intel_primary_plane_create(struct drm_i9 primary->frontbuffer_bit = INTEL_FRONTBUFFER_PRIMARY(pipe); primary->check_plane = intel_check_primary_plane; - if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv)) { + if (INTEL_GEN(dev_priv) >= 10) { intel_primary_formats = skl_primary_formats; num_formats = ARRAY_SIZE(skl_primary_formats); modifiers = skl_format_modifiers_ccs; Patches currently in stable-queue which might be from krisman(a)collabora.co.uk are queue-4.14/i915-reject-ccs-modifiers-for-pipe-c-on-geminilake.patch

7 years, 4 months

1
0
0 0

Patch "i40e/i40evf: Account for frags split over multiple descriptors in check linearize" 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/i40evf: Account for frags split over multiple descriptors in check linearize 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-i40evf-account-for-frags-split-over-multiple-descriptors-in-check-linearize.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Wed Feb 28 16:23:28 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)verizon.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 @@ -3048,10 +3048,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; @@ -3059,7 +3079,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 @@ -2014,10 +2014,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; @@ -2025,7 +2045,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.14/i40e-i40evf-account-for-frags-split-over-multiple-descriptors-in-check-linearize.patch

7 years, 4 months

1
0
0 0

Patch "i40e: don't remove netdev->dev_addr when syncing uc list" 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: don't remove netdev->dev_addr when syncing uc list 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-don-t-remove-netdev-dev_addr-when-syncing-uc-list.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Wed Feb 28 16:23:28 CET 2018 From: Jacob Keller <jacob.e.keller(a)intel.com> Date: Wed, 20 Dec 2017 11:04:36 -0500 Subject: i40e: don't remove netdev->dev_addr when syncing uc list From: Jacob Keller <jacob.e.keller(a)intel.com> [ Upstream commit 458867b2ca0c987445c5d9adccd1642970e1ba07 ] In some circumstances, such as with bridging, it is possible that the stack will add a devices own MAC address to its unicast address list. If, later, the stack deletes this address, then the i40e driver will receive a request to remove this address. The driver stores its current MAC address as part of the MAC/VLAN hash array, since it is convenient and matches exactly how the hardware expects to be told which traffic to receive. This causes a problem, since for more devices, the MAC address is stored separately, and requests to delete a unicast address should not have the ability to remove the filter for the MAC address. Fix this by forcing a check on every address sync to ensure we do not remove the device address. There is a very narrow possibility of a race between .set_mac and .set_rx_mode, if we don't change netdev->dev_addr before updating our internal MAC list in .set_mac. This might be possible if .set_rx_mode is going to remove MAC "XYZ" from the list, at the same time as .set_mac changes our dev_addr to MAC "XYZ", we might possibly queue a delete, then an add in .set_mac, then queue a delete in .set_rx_mode's dev_uc_sync and then update netdev->dev_addr. We can avoid this by moving the copy into dev_addr prior to the changes to the MAC filter list. A similar race on the other side does not cause problems, as if we're changing our MAC form A to B, and we race with .set_rx_mode, it could queue a delete from A, we'd update our address, and allow the delete. This seems like a race, but in reality we're about to queue a delete of A anyways, so it would not cause any issues. A race in the initialization code is unlikely because the netdevice has not yet been fully initialized and the stack should not be adding or removing addresses yet. Note that we don't (yet) need similar code for the VF driver because it does not make use of __dev_uc_sync and __dev_mc_sync, but instead roles its own method for handling updates to the MAC/VLAN list, which already has code to protect against removal of the hardware address. Signed-off-by: Jacob Keller <jacob.e.keller(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)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/intel/i40e/i40e_main.c | 17 ++++++++++++++++- 1 file changed, 16 insertions(+), 1 deletion(-) --- a/drivers/net/ethernet/intel/i40e/i40e_main.c +++ b/drivers/net/ethernet/intel/i40e/i40e_main.c @@ -1553,11 +1553,18 @@ static int i40e_set_mac(struct net_devic else netdev_info(netdev, "set new mac address %pM\n", addr->sa_data); + /* Copy the address first, so that we avoid a possible race with + * .set_rx_mode(). If we copy after changing the address in the filter + * list, we might open ourselves to a narrow race window where + * .set_rx_mode could delete our dev_addr filter and prevent traffic + * from passing. + */ + ether_addr_copy(netdev->dev_addr, addr->sa_data); + spin_lock_bh(&vsi->mac_filter_hash_lock); i40e_del_mac_filter(vsi, netdev->dev_addr); i40e_add_mac_filter(vsi, addr->sa_data); spin_unlock_bh(&vsi->mac_filter_hash_lock); - ether_addr_copy(netdev->dev_addr, addr->sa_data); if (vsi->type == I40E_VSI_MAIN) { i40e_status ret; @@ -1739,6 +1746,14 @@ static int i40e_addr_unsync(struct net_d struct i40e_netdev_priv *np = netdev_priv(netdev); struct i40e_vsi *vsi = np->vsi; + /* Under some circumstances, we might receive a request to delete + * our own device address from our uc list. Because we store the + * device address in the VSI's MAC/VLAN filter list, we need to ignore + * such requests and not delete our device address from this list. + */ + if (ether_addr_equal(addr, netdev->dev_addr)) + return 0; + i40e_del_mac_filter(vsi, addr); return 0; Patches currently in stable-queue which might be from jacob.e.keller(a)intel.com are queue-4.14/i40e-don-t-remove-netdev-dev_addr-when-syncing-uc-list.patch

7 years, 4 months

1
0
0 0

Patch "genirq: Guard handle_bad_irq log messages" 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 genirq: Guard handle_bad_irq log messages 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: genirq-guard-handle_bad_irq-log-messages.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Wed Feb 28 16:23:28 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)verizon.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 @@ -12,6 +12,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.14/genirq-guard-handle_bad_irq-log-messages.patch

7 years, 4 months

1
0
0 0

Patch "exec: avoid gcc-8 warning for get_task_comm" 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 exec: avoid gcc-8 warning for get_task_comm 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: exec-avoid-gcc-8-warning-for-get_task_comm.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Wed Feb 28 16:23:28 CET 2018 From: Arnd Bergmann <arnd(a)arndb.de> Date: Thu, 14 Dec 2017 15:32:41 -0800 Subject: exec: avoid gcc-8 warning for get_task_comm From: Arnd Bergmann <arnd(a)arndb.de> [ Upstream commit 3756f6401c302617c5e091081ca4d26ab604bec5 ] gcc-8 warns about using strncpy() with the source size as the limit: fs/exec.c:1223:32: error: argument to 'sizeof' in 'strncpy' call is the same expression as the source; did you mean to use the size of the destination? [-Werror=sizeof-pointer-memaccess] This is indeed slightly suspicious, as it protects us from source arguments without NUL-termination, but does not guarantee that the destination is terminated. This keeps the strncpy() to ensure we have properly padded target buffer, but ensures that we use the correct length, by passing the actual length of the destination buffer as well as adding a build-time check to ensure it is exactly TASK_COMM_LEN. There are only 23 callsites which I all reviewed to ensure this is currently the case. We could get away with doing only the check or passing the right length, but it doesn't hurt to do both. Link: http://lkml.kernel.org/r/20171205151724.1764896-1-arnd@arndb.de Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> Suggested-by: Kees Cook <keescook(a)chromium.org> Acked-by: Kees Cook <keescook(a)chromium.org> Acked-by: Ingo Molnar <mingo(a)kernel.org> Cc: Alexander Viro <viro(a)zeniv.linux.org.uk> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Serge Hallyn <serge(a)hallyn.com> Cc: James Morris <james.l.morris(a)oracle.com> Cc: Aleksa Sarai <asarai(a)suse.de> Cc: "Eric W. Biederman" <ebiederm(a)xmission.com> Cc: Frederic Weisbecker <frederic(a)kernel.org> Cc: Thomas Gleixner <tglx(a)linutronix.de> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/exec.c | 7 +++---- include/linux/sched.h | 6 +++++- 2 files changed, 8 insertions(+), 5 deletions(-) --- a/fs/exec.c +++ b/fs/exec.c @@ -1216,15 +1216,14 @@ killed: return -EAGAIN; } -char *get_task_comm(char *buf, struct task_struct *tsk) +char *__get_task_comm(char *buf, size_t buf_size, struct task_struct *tsk) { - /* buf must be at least sizeof(tsk->comm) in size */ task_lock(tsk); - strncpy(buf, tsk->comm, sizeof(tsk->comm)); + strncpy(buf, tsk->comm, buf_size); task_unlock(tsk); return buf; } -EXPORT_SYMBOL_GPL(get_task_comm); +EXPORT_SYMBOL_GPL(__get_task_comm); /* * These functions flushes out all traces of the currently running executable --- a/include/linux/sched.h +++ b/include/linux/sched.h @@ -1502,7 +1502,11 @@ static inline void set_task_comm(struct __set_task_comm(tsk, from, false); } -extern char *get_task_comm(char *to, struct task_struct *tsk); +extern char *__get_task_comm(char *to, size_t len, struct task_struct *tsk); +#define get_task_comm(buf, tsk) ({ \ + BUILD_BUG_ON(sizeof(buf) != TASK_COMM_LEN); \ + __get_task_comm(buf, sizeof(buf), tsk); \ +}) #ifdef CONFIG_SMP void scheduler_ipi(void); Patches currently in stable-queue which might be from arnd(a)arndb.de are queue-4.14/exec-avoid-gcc-8-warning-for-get_task_comm.patch queue-4.14/x86-asm-allow-again-using-asm.h-when-building-for-the-bpf-clang-target.patch queue-4.14/arm-dts-ls1021a-fix-incorrect-clock-references.patch

7 years, 4 months

1
0
0 0

Patch "e1000: fix disabling already-disabled warning" 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 e1000: fix disabling already-disabled warning 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: e1000-fix-disabling-already-disabled-warning.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Wed Feb 28 16:23:28 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)verizon.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 @@ -945,7 +945,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; @@ -955,6 +955,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); @@ -1259,11 +1260,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; } @@ -1281,6 +1284,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); @@ -1299,9 +1303,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); } /** @@ -5156,7 +5162,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; } @@ -5200,6 +5207,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); @@ -5274,7 +5285,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; @@ -5302,6 +5315,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.14/e1000-fix-disabling-already-disabled-warning.patch

7 years, 4 months

1
0
0 0

Patch "drm/ttm: check the return value of kzalloc" 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 drm/ttm: check the return value of kzalloc 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: drm-ttm-check-the-return-value-of-kzalloc.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Wed Feb 28 16:23:28 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)verizon.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 @@ -821,6 +821,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.14/drm-ttm-check-the-return-value-of-kzalloc.patch

7 years, 4 months

1
0
0 0

Patch "drm/nouveau/pci: do a msi rearm on init" 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 drm/nouveau/pci: do a msi rearm on init 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: drm-nouveau-pci-do-a-msi-rearm-on-init.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Wed Feb 28 16:23:28 CET 2018 From: Karol Herbst <kherbst(a)redhat.com> Date: Fri, 24 Nov 2017 03:56:26 +0100 Subject: drm/nouveau/pci: do a msi rearm on init From: Karol Herbst <kherbst(a)redhat.com> [ Upstream commit a121027d2747168df0aac0c3da35509eea39f61c ] On my GP107 when I load nouveau after unloading it, for some reason the GPU stopped sending or the CPU stopped receiving interrupts if MSI was enabled. Doing a rearm once before getting any interrupts fixes this. Signed-off-by: Karol Herbst <kherbst(a)redhat.com> Reviewed-by: Thierry Reding <treding(a)nvidia.com> Signed-off-by: Ben Skeggs <bskeggs(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/gpu/drm/nouveau/nvkm/subdev/pci/base.c | 7 +++++++ 1 file changed, 7 insertions(+) --- a/drivers/gpu/drm/nouveau/nvkm/subdev/pci/base.c +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/pci/base.c @@ -136,6 +136,13 @@ nvkm_pci_init(struct nvkm_subdev *subdev return ret; pci->irq = pdev->irq; + + /* Ensure MSI interrupts are armed, for the case where there are + * already interrupts pending (for whatever reason) at load time. + */ + if (pci->msi) + pci->func->msi_rearm(pci); + return ret; } Patches currently in stable-queue which might be from kherbst(a)redhat.com are queue-4.14/drm-nouveau-pci-do-a-msi-rearm-on-init.patch

7 years, 4 months

1
0
0 0

Patch "dmaengine: fsl-edma: disable clks on all error paths" 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 dmaengine: fsl-edma: disable clks on all error paths 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: dmaengine-fsl-edma-disable-clks-on-all-error-paths.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Wed Feb 28 16:23:28 CET 2018 From: Andreas Platschek <andreas.platschek(a)opentech.at> Date: Thu, 14 Dec 2017 12:50:51 +0100 Subject: dmaengine: fsl-edma: disable clks on all error paths From: Andreas Platschek <andreas.platschek(a)opentech.at> [ Upstream commit 2610acf46b9ed528ec2cacd717bc9d354e452b73 ] Previously enabled clks are only disabled if clk_prepare_enable() fails. However, there are other error paths were the previously enabled clocks are not disabled. To fix the problem, fsl_disable_clocks() now takes the number of clocks that shall be disabled + unprepared. For existing calls were all clocks were already successfully prepared + enabled, DMAMUX_NR is passed to disable + unprepare all clocks. In error paths were only some clocks were successfully prepared + enabled the loop counter is passed, in order to disable + unprepare all successfully prepared + enabled clocks. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Andreas Platschek <andreas.platschek(a)opentech.at> 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/fsl-edma.c | 28 ++++++++++++++-------------- 1 file changed, 14 insertions(+), 14 deletions(-) --- a/drivers/dma/fsl-edma.c +++ b/drivers/dma/fsl-edma.c @@ -863,11 +863,11 @@ static void fsl_edma_irq_exit( } } -static void fsl_disable_clocks(struct fsl_edma_engine *fsl_edma) +static void fsl_disable_clocks(struct fsl_edma_engine *fsl_edma, int nr_clocks) { int i; - for (i = 0; i < DMAMUX_NR; i++) + for (i = 0; i < nr_clocks; i++) clk_disable_unprepare(fsl_edma->muxclk[i]); } @@ -904,25 +904,25 @@ static int fsl_edma_probe(struct platfor res = platform_get_resource(pdev, IORESOURCE_MEM, 1 + i); fsl_edma->muxbase[i] = devm_ioremap_resource(&pdev->dev, res); - if (IS_ERR(fsl_edma->muxbase[i])) + if (IS_ERR(fsl_edma->muxbase[i])) { + /* on error: disable all previously enabled clks */ + fsl_disable_clocks(fsl_edma, i); return PTR_ERR(fsl_edma->muxbase[i]); + } sprintf(clkname, "dmamux%d", i); fsl_edma->muxclk[i] = devm_clk_get(&pdev->dev, clkname); if (IS_ERR(fsl_edma->muxclk[i])) { dev_err(&pdev->dev, "Missing DMAMUX block clock.\n"); + /* on error: disable all previously enabled clks */ + fsl_disable_clocks(fsl_edma, i); return PTR_ERR(fsl_edma->muxclk[i]); } ret = clk_prepare_enable(fsl_edma->muxclk[i]); - if (ret) { - /* disable only clks which were enabled on error */ - for (; i >= 0; i--) - clk_disable_unprepare(fsl_edma->muxclk[i]); - - dev_err(&pdev->dev, "DMAMUX clk block failed.\n"); - return ret; - } + if (ret) + /* on error: disable all previously enabled clks */ + fsl_disable_clocks(fsl_edma, i); } @@ -976,7 +976,7 @@ static int fsl_edma_probe(struct platfor if (ret) { dev_err(&pdev->dev, "Can't register Freescale eDMA engine. (%d)\n", ret); - fsl_disable_clocks(fsl_edma); + fsl_disable_clocks(fsl_edma, DMAMUX_NR); return ret; } @@ -985,7 +985,7 @@ static int fsl_edma_probe(struct platfor dev_err(&pdev->dev, "Can't register Freescale eDMA of_dma. (%d)\n", ret); dma_async_device_unregister(&fsl_edma->dma_dev); - fsl_disable_clocks(fsl_edma); + fsl_disable_clocks(fsl_edma, DMAMUX_NR); return ret; } @@ -1015,7 +1015,7 @@ static int fsl_edma_remove(struct platfo fsl_edma_cleanup_vchan(&fsl_edma->dma_dev); of_dma_controller_free(np); dma_async_device_unregister(&fsl_edma->dma_dev); - fsl_disable_clocks(fsl_edma); + fsl_disable_clocks(fsl_edma, DMAMUX_NR); return 0; } Patches currently in stable-queue which might be from andreas.platschek(a)opentech.at are queue-4.14/dmaengine-fsl-edma-disable-clks-on-all-error-paths.patch

7 years, 4 months

1
0
0 0

Patch "crypto: inside-secure - per request invalidation" 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 crypto: inside-secure - per request invalidation 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: crypto-inside-secure-per-request-invalidation.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Wed Feb 28 16:23:28 CET 2018 From: Ofer Heifetz <oferh(a)marvell.com> Date: Mon, 11 Dec 2017 12:10:55 +0100 Subject: crypto: inside-secure - per request invalidation From: Ofer Heifetz <oferh(a)marvell.com> [ Upstream commit 1eb7b40386c97f6c4d1c62931bf306f4535a4bd6 ] When an invalidation request is needed we currently override the context .send and .handle_result helpers. This is wrong as under high load other requests can already be queued and overriding the context helpers will make them execute the wrong .send and .handle_result functions. This commit fixes this by adding a needs_inv flag in the request to choose the action to perform when sending requests or handling their results. This flag will be set when needed (i.e. when the context flag will be set). Fixes: 1b44c5a60c13 ("crypto: inside-secure - add SafeXcel EIP197 crypto engine driver") Signed-off-by: Ofer Heifetz <oferh(a)marvell.com> [Antoine: commit message, and removed non related changes from the original commit] Signed-off-by: Antoine Tenart <antoine.tenart(a)free-electrons.com> 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/inside-secure/safexcel_cipher.c | 71 ++++++++++++++++++++----- drivers/crypto/inside-secure/safexcel_hash.c | 67 ++++++++++++++++++----- 2 files changed, 111 insertions(+), 27 deletions(-) --- a/drivers/crypto/inside-secure/safexcel_cipher.c +++ b/drivers/crypto/inside-secure/safexcel_cipher.c @@ -14,6 +14,7 @@ #include <crypto/aes.h> #include <crypto/skcipher.h> +#include <crypto/internal/skcipher.h> #include "safexcel.h" @@ -33,6 +34,10 @@ struct safexcel_cipher_ctx { unsigned int key_len; }; +struct safexcel_cipher_req { + bool needs_inv; +}; + static void safexcel_cipher_token(struct safexcel_cipher_ctx *ctx, struct crypto_async_request *async, struct safexcel_command_desc *cdesc, @@ -126,9 +131,9 @@ static int safexcel_context_control(stru return 0; } -static int safexcel_handle_result(struct safexcel_crypto_priv *priv, int ring, - struct crypto_async_request *async, - bool *should_complete, int *ret) +static int safexcel_handle_req_result(struct safexcel_crypto_priv *priv, int ring, + struct crypto_async_request *async, + bool *should_complete, int *ret) { struct skcipher_request *req = skcipher_request_cast(async); struct safexcel_result_desc *rdesc; @@ -265,7 +270,6 @@ static int safexcel_aes_send(struct cryp spin_unlock_bh(&priv->ring[ring].egress_lock); request->req = &req->base; - ctx->base.handle_result = safexcel_handle_result; *commands = n_cdesc; *results = n_rdesc; @@ -341,8 +345,6 @@ static int safexcel_handle_inv_result(st ring = safexcel_select_ring(priv); ctx->base.ring = ring; - ctx->base.needs_inv = false; - ctx->base.send = safexcel_aes_send; spin_lock_bh(&priv->ring[ring].queue_lock); enq_ret = crypto_enqueue_request(&priv->ring[ring].queue, async); @@ -359,6 +361,26 @@ static int safexcel_handle_inv_result(st return ndesc; } +static int safexcel_handle_result(struct safexcel_crypto_priv *priv, int ring, + struct crypto_async_request *async, + bool *should_complete, int *ret) +{ + struct skcipher_request *req = skcipher_request_cast(async); + struct safexcel_cipher_req *sreq = skcipher_request_ctx(req); + int err; + + if (sreq->needs_inv) { + sreq->needs_inv = false; + err = safexcel_handle_inv_result(priv, ring, async, + should_complete, ret); + } else { + err = safexcel_handle_req_result(priv, ring, async, + should_complete, ret); + } + + return err; +} + static int safexcel_cipher_send_inv(struct crypto_async_request *async, int ring, struct safexcel_request *request, int *commands, int *results) @@ -368,8 +390,6 @@ static int safexcel_cipher_send_inv(stru struct safexcel_crypto_priv *priv = ctx->priv; int ret; - ctx->base.handle_result = safexcel_handle_inv_result; - ret = safexcel_invalidate_cache(async, &ctx->base, priv, ctx->base.ctxr_dma, ring, request); if (unlikely(ret)) @@ -381,11 +401,29 @@ static int safexcel_cipher_send_inv(stru return 0; } +static int safexcel_send(struct crypto_async_request *async, + int ring, struct safexcel_request *request, + int *commands, int *results) +{ + struct skcipher_request *req = skcipher_request_cast(async); + struct safexcel_cipher_req *sreq = skcipher_request_ctx(req); + int ret; + + if (sreq->needs_inv) + ret = safexcel_cipher_send_inv(async, ring, request, + commands, results); + else + ret = safexcel_aes_send(async, ring, request, + commands, results); + return ret; +} + static int safexcel_cipher_exit_inv(struct crypto_tfm *tfm) { struct safexcel_cipher_ctx *ctx = crypto_tfm_ctx(tfm); struct safexcel_crypto_priv *priv = ctx->priv; struct skcipher_request req; + struct safexcel_cipher_req *sreq = skcipher_request_ctx(&req); struct safexcel_inv_result result = {}; int ring = ctx->base.ring; @@ -399,7 +437,7 @@ static int safexcel_cipher_exit_inv(stru skcipher_request_set_tfm(&req, __crypto_skcipher_cast(tfm)); ctx = crypto_tfm_ctx(req.base.tfm); ctx->base.exit_inv = true; - ctx->base.send = safexcel_cipher_send_inv; + sreq->needs_inv = true; spin_lock_bh(&priv->ring[ring].queue_lock); crypto_enqueue_request(&priv->ring[ring].queue, &req.base); @@ -424,19 +462,21 @@ static int safexcel_aes(struct skcipher_ enum safexcel_cipher_direction dir, u32 mode) { struct safexcel_cipher_ctx *ctx = crypto_tfm_ctx(req->base.tfm); + struct safexcel_cipher_req *sreq = skcipher_request_ctx(req); struct safexcel_crypto_priv *priv = ctx->priv; int ret, ring; + sreq->needs_inv = false; ctx->direction = dir; ctx->mode = mode; if (ctx->base.ctxr) { - if (ctx->base.needs_inv) - ctx->base.send = safexcel_cipher_send_inv; + if (ctx->base.needs_inv) { + sreq->needs_inv = true; + ctx->base.needs_inv = false; + } } else { ctx->base.ring = safexcel_select_ring(priv); - ctx->base.send = safexcel_aes_send; - ctx->base.ctxr = dma_pool_zalloc(priv->context_pool, EIP197_GFP_FLAGS(req->base), &ctx->base.ctxr_dma); @@ -476,6 +516,11 @@ static int safexcel_skcipher_cra_init(st alg.skcipher.base); ctx->priv = tmpl->priv; + ctx->base.send = safexcel_send; + ctx->base.handle_result = safexcel_handle_result; + + crypto_skcipher_set_reqsize(__crypto_skcipher_cast(tfm), + sizeof(struct safexcel_cipher_req)); return 0; } --- a/drivers/crypto/inside-secure/safexcel_hash.c +++ b/drivers/crypto/inside-secure/safexcel_hash.c @@ -32,6 +32,7 @@ struct safexcel_ahash_req { bool last_req; bool finish; bool hmac; + bool needs_inv; int nents; @@ -121,9 +122,9 @@ static void safexcel_context_control(str } } -static int safexcel_handle_result(struct safexcel_crypto_priv *priv, int ring, - struct crypto_async_request *async, - bool *should_complete, int *ret) +static int safexcel_handle_req_result(struct safexcel_crypto_priv *priv, int ring, + struct crypto_async_request *async, + bool *should_complete, int *ret) { struct safexcel_result_desc *rdesc; struct ahash_request *areq = ahash_request_cast(async); @@ -169,9 +170,9 @@ static int safexcel_handle_result(struct return 1; } -static int safexcel_ahash_send(struct crypto_async_request *async, int ring, - struct safexcel_request *request, int *commands, - int *results) +static int safexcel_ahash_send_req(struct crypto_async_request *async, int ring, + struct safexcel_request *request, + int *commands, int *results) { struct ahash_request *areq = ahash_request_cast(async); struct crypto_ahash *ahash = crypto_ahash_reqtfm(areq); @@ -310,7 +311,6 @@ send_command: req->processed += len; request->req = &areq->base; - ctx->base.handle_result = safexcel_handle_result; *commands = n_cdesc; *results = 1; @@ -394,8 +394,6 @@ static int safexcel_handle_inv_result(st ring = safexcel_select_ring(priv); ctx->base.ring = ring; - ctx->base.needs_inv = false; - ctx->base.send = safexcel_ahash_send; spin_lock_bh(&priv->ring[ring].queue_lock); enq_ret = crypto_enqueue_request(&priv->ring[ring].queue, async); @@ -412,6 +410,26 @@ static int safexcel_handle_inv_result(st return 1; } +static int safexcel_handle_result(struct safexcel_crypto_priv *priv, int ring, + struct crypto_async_request *async, + bool *should_complete, int *ret) +{ + struct ahash_request *areq = ahash_request_cast(async); + struct safexcel_ahash_req *req = ahash_request_ctx(areq); + int err; + + if (req->needs_inv) { + req->needs_inv = false; + err = safexcel_handle_inv_result(priv, ring, async, + should_complete, ret); + } else { + err = safexcel_handle_req_result(priv, ring, async, + should_complete, ret); + } + + return err; +} + static int safexcel_ahash_send_inv(struct crypto_async_request *async, int ring, struct safexcel_request *request, int *commands, int *results) @@ -420,7 +438,6 @@ static int safexcel_ahash_send_inv(struc struct safexcel_ahash_ctx *ctx = crypto_ahash_ctx(crypto_ahash_reqtfm(areq)); int ret; - ctx->base.handle_result = safexcel_handle_inv_result; ret = safexcel_invalidate_cache(async, &ctx->base, ctx->priv, ctx->base.ctxr_dma, ring, request); if (unlikely(ret)) @@ -432,11 +449,29 @@ static int safexcel_ahash_send_inv(struc return 0; } +static int safexcel_ahash_send(struct crypto_async_request *async, + int ring, struct safexcel_request *request, + int *commands, int *results) +{ + struct ahash_request *areq = ahash_request_cast(async); + struct safexcel_ahash_req *req = ahash_request_ctx(areq); + int ret; + + if (req->needs_inv) + ret = safexcel_ahash_send_inv(async, ring, request, + commands, results); + else + ret = safexcel_ahash_send_req(async, ring, request, + commands, results); + return ret; +} + static int safexcel_ahash_exit_inv(struct crypto_tfm *tfm) { struct safexcel_ahash_ctx *ctx = crypto_tfm_ctx(tfm); struct safexcel_crypto_priv *priv = ctx->priv; struct ahash_request req; + struct safexcel_ahash_req *rctx = ahash_request_ctx(&req); struct safexcel_inv_result result = {}; int ring = ctx->base.ring; @@ -450,7 +485,7 @@ static int safexcel_ahash_exit_inv(struc ahash_request_set_tfm(&req, __crypto_ahash_cast(tfm)); ctx = crypto_tfm_ctx(req.base.tfm); ctx->base.exit_inv = true; - ctx->base.send = safexcel_ahash_send_inv; + rctx->needs_inv = true; spin_lock_bh(&priv->ring[ring].queue_lock); crypto_enqueue_request(&priv->ring[ring].queue, &req.base); @@ -501,14 +536,16 @@ static int safexcel_ahash_enqueue(struct struct safexcel_crypto_priv *priv = ctx->priv; int ret, ring; - ctx->base.send = safexcel_ahash_send; + req->needs_inv = false; if (req->processed && ctx->digest == CONTEXT_CONTROL_DIGEST_PRECOMPUTED) ctx->base.needs_inv = safexcel_ahash_needs_inv_get(areq); if (ctx->base.ctxr) { - if (ctx->base.needs_inv) - ctx->base.send = safexcel_ahash_send_inv; + if (ctx->base.needs_inv) { + ctx->base.needs_inv = false; + req->needs_inv = true; + } } else { ctx->base.ring = safexcel_select_ring(priv); ctx->base.ctxr = dma_pool_zalloc(priv->context_pool, @@ -642,6 +679,8 @@ static int safexcel_ahash_cra_init(struc struct safexcel_alg_template, alg.ahash); ctx->priv = tmpl->priv; + ctx->base.send = safexcel_ahash_send; + ctx->base.handle_result = safexcel_handle_result; crypto_ahash_set_reqsize(__crypto_ahash_cast(tfm), sizeof(struct safexcel_ahash_req)); Patches currently in stable-queue which might be from oferh(a)marvell.com are queue-4.14/crypto-inside-secure-per-request-invalidation.patch queue-4.14/crypto-inside-secure-fix-request-allocations-in-invalidation-path.patch queue-4.14/crypto-inside-secure-free-requests-even-if-their-handling-failed.patch

7 years, 4 months

1
0
0 0

Patch "crypto: inside-secure - free requests even if their handling failed" 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 crypto: inside-secure - free requests even if their handling failed 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: crypto-inside-secure-free-requests-even-if-their-handling-failed.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Wed Feb 28 16:23:28 CET 2018 From: "Antoine Ténart" <antoine.tenart(a)free-electrons.com> Date: Mon, 11 Dec 2017 12:10:56 +0100 Subject: crypto: inside-secure - free requests even if their handling failed From: "Antoine Ténart" <antoine.tenart(a)free-electrons.com> [ Upstream commit 0a02dcca126280595950f3ea809f77c9cb0a235c ] This patch frees the request private data even if its handling failed, as it would never be freed otherwise. Fixes: 1b44c5a60c13 ("crypto: inside-secure - add SafeXcel EIP197 crypto engine driver") Suggested-by: Ofer Heifetz <oferh(a)marvell.com> Signed-off-by: Antoine Tenart <antoine.tenart(a)free-electrons.com> 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/inside-secure/safexcel.c | 1 + 1 file changed, 1 insertion(+) --- a/drivers/crypto/inside-secure/safexcel.c +++ b/drivers/crypto/inside-secure/safexcel.c @@ -607,6 +607,7 @@ static inline void safexcel_handle_resul ndesc = ctx->handle_result(priv, ring, sreq->req, &should_complete, &ret); if (ndesc < 0) { + kfree(sreq); dev_err(priv->dev, "failed to handle result (%d)", ndesc); return; } Patches currently in stable-queue which might be from antoine.tenart(a)free-electrons.com are queue-4.14/crypto-inside-secure-per-request-invalidation.patch queue-4.14/crypto-inside-secure-fix-request-allocations-in-invalidation-path.patch queue-4.14/crypto-inside-secure-free-requests-even-if-their-handling-failed.patch

7 years, 4 months

1
0
0 0

Patch "crypto: inside-secure - fix request allocations in invalidation path" 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 crypto: inside-secure - fix request allocations in invalidation path 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: crypto-inside-secure-fix-request-allocations-in-invalidation-path.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Wed Feb 28 16:23:28 CET 2018 From: "Antoine Ténart" <antoine.tenart(a)free-electrons.com> Date: Mon, 11 Dec 2017 12:10:57 +0100 Subject: crypto: inside-secure - fix request allocations in invalidation path From: "Antoine Ténart" <antoine.tenart(a)free-electrons.com> [ Upstream commit 7cad2fabd5691dbb17762877d4e7f236fe4bc181 ] This patch makes use of the SKCIPHER_REQUEST_ON_STACK and AHASH_REQUEST_ON_STACK helpers to allocate enough memory to contain both the crypto request structures and their embedded context (__ctx). Fixes: 1b44c5a60c13 ("crypto: inside-secure - add SafeXcel EIP197 crypto engine driver") Suggested-by: Ofer Heifetz <oferh(a)marvell.com> Signed-off-by: Antoine Tenart <antoine.tenart(a)free-electrons.com> 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/inside-secure/safexcel_cipher.c | 16 ++++++++-------- drivers/crypto/inside-secure/safexcel_hash.c | 14 +++++++------- 2 files changed, 15 insertions(+), 15 deletions(-) --- a/drivers/crypto/inside-secure/safexcel_cipher.c +++ b/drivers/crypto/inside-secure/safexcel_cipher.c @@ -422,25 +422,25 @@ static int safexcel_cipher_exit_inv(stru { struct safexcel_cipher_ctx *ctx = crypto_tfm_ctx(tfm); struct safexcel_crypto_priv *priv = ctx->priv; - struct skcipher_request req; - struct safexcel_cipher_req *sreq = skcipher_request_ctx(&req); + SKCIPHER_REQUEST_ON_STACK(req, __crypto_skcipher_cast(tfm)); + struct safexcel_cipher_req *sreq = skcipher_request_ctx(req); struct safexcel_inv_result result = {}; int ring = ctx->base.ring; - memset(&req, 0, sizeof(struct skcipher_request)); + memset(req, 0, sizeof(struct skcipher_request)); /* create invalidation request */ init_completion(&result.completion); - skcipher_request_set_callback(&req, CRYPTO_TFM_REQ_MAY_BACKLOG, - safexcel_inv_complete, &result); + skcipher_request_set_callback(req, CRYPTO_TFM_REQ_MAY_BACKLOG, + safexcel_inv_complete, &result); - skcipher_request_set_tfm(&req, __crypto_skcipher_cast(tfm)); - ctx = crypto_tfm_ctx(req.base.tfm); + skcipher_request_set_tfm(req, __crypto_skcipher_cast(tfm)); + ctx = crypto_tfm_ctx(req->base.tfm); ctx->base.exit_inv = true; sreq->needs_inv = true; spin_lock_bh(&priv->ring[ring].queue_lock); - crypto_enqueue_request(&priv->ring[ring].queue, &req.base); + crypto_enqueue_request(&priv->ring[ring].queue, &req->base); spin_unlock_bh(&priv->ring[ring].queue_lock); if (!priv->ring[ring].need_dequeue) --- a/drivers/crypto/inside-secure/safexcel_hash.c +++ b/drivers/crypto/inside-secure/safexcel_hash.c @@ -470,25 +470,25 @@ static int safexcel_ahash_exit_inv(struc { struct safexcel_ahash_ctx *ctx = crypto_tfm_ctx(tfm); struct safexcel_crypto_priv *priv = ctx->priv; - struct ahash_request req; - struct safexcel_ahash_req *rctx = ahash_request_ctx(&req); + AHASH_REQUEST_ON_STACK(req, __crypto_ahash_cast(tfm)); + struct safexcel_ahash_req *rctx = ahash_request_ctx(req); struct safexcel_inv_result result = {}; int ring = ctx->base.ring; - memset(&req, 0, sizeof(struct ahash_request)); + memset(req, 0, sizeof(struct ahash_request)); /* create invalidation request */ init_completion(&result.completion); - ahash_request_set_callback(&req, CRYPTO_TFM_REQ_MAY_BACKLOG, + ahash_request_set_callback(req, CRYPTO_TFM_REQ_MAY_BACKLOG, safexcel_inv_complete, &result); - ahash_request_set_tfm(&req, __crypto_ahash_cast(tfm)); - ctx = crypto_tfm_ctx(req.base.tfm); + ahash_request_set_tfm(req, __crypto_ahash_cast(tfm)); + ctx = crypto_tfm_ctx(req->base.tfm); ctx->base.exit_inv = true; rctx->needs_inv = true; spin_lock_bh(&priv->ring[ring].queue_lock); - crypto_enqueue_request(&priv->ring[ring].queue, &req.base); + crypto_enqueue_request(&priv->ring[ring].queue, &req->base); spin_unlock_bh(&priv->ring[ring].queue_lock); if (!priv->ring[ring].need_dequeue) Patches currently in stable-queue which might be from antoine.tenart(a)free-electrons.com are queue-4.14/crypto-inside-secure-per-request-invalidation.patch queue-4.14/crypto-inside-secure-fix-request-allocations-in-invalidation-path.patch queue-4.14/crypto-inside-secure-free-requests-even-if-their-handling-failed.patch

7 years, 4 months

1
0
0 0

Patch "crypto: af_alg - Fix race around ctx->rcvused by making it atomic_t" 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 crypto: af_alg - Fix race around ctx->rcvused by making it atomic_t 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: crypto-af_alg-fix-race-around-ctx-rcvused-by-making-it-atomic_t.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Wed Feb 28 16:23:28 CET 2018 From: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> Date: Tue, 19 Dec 2017 10:27:24 +0000 Subject: crypto: af_alg - Fix race around ctx->rcvused by making it atomic_t From: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> [ Upstream commit af955bf15d2c27496b0269b1f05c26f758c68314 ] This variable was increased and decreased without any protection. Result was an occasional misscount and negative wrap around resulting in false resource allocation failures. Fixes: 7d2c3f54e6f6 ("crypto: af_alg - remove locking in async callback") Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> Reviewed-by: Stephan Mueller <smueller(a)chronox.de> 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> --- crypto/af_alg.c | 4 ++-- crypto/algif_aead.c | 2 +- crypto/algif_skcipher.c | 2 +- include/crypto/if_alg.h | 5 +++-- 4 files changed, 7 insertions(+), 6 deletions(-) --- a/crypto/af_alg.c +++ b/crypto/af_alg.c @@ -693,7 +693,7 @@ void af_alg_free_areq_sgls(struct af_alg unsigned int i; list_for_each_entry_safe(rsgl, tmp, &areq->rsgl_list, list) { - ctx->rcvused -= rsgl->sg_num_bytes; + atomic_sub(rsgl->sg_num_bytes, &ctx->rcvused); af_alg_free_sg(&rsgl->sgl); list_del(&rsgl->list); if (rsgl != &areq->first_rsgl) @@ -1192,7 +1192,7 @@ int af_alg_get_rsgl(struct sock *sk, str areq->last_rsgl = rsgl; len += err; - ctx->rcvused += err; + atomic_add(err, &ctx->rcvused); rsgl->sg_num_bytes = err; iov_iter_advance(&msg->msg_iter, err); } --- a/crypto/algif_aead.c +++ b/crypto/algif_aead.c @@ -571,7 +571,7 @@ static int aead_accept_parent_nokey(void INIT_LIST_HEAD(&ctx->tsgl_list); ctx->len = len; ctx->used = 0; - ctx->rcvused = 0; + atomic_set(&ctx->rcvused, 0); ctx->more = 0; ctx->merge = 0; ctx->enc = 0; --- a/crypto/algif_skcipher.c +++ b/crypto/algif_skcipher.c @@ -391,7 +391,7 @@ static int skcipher_accept_parent_nokey( INIT_LIST_HEAD(&ctx->tsgl_list); ctx->len = len; ctx->used = 0; - ctx->rcvused = 0; + atomic_set(&ctx->rcvused, 0); ctx->more = 0; ctx->merge = 0; ctx->enc = 0; --- a/include/crypto/if_alg.h +++ b/include/crypto/if_alg.h @@ -18,6 +18,7 @@ #include <linux/if_alg.h> #include <linux/scatterlist.h> #include <linux/types.h> +#include <linux/atomic.h> #include <net/sock.h> #include <crypto/aead.h> @@ -155,7 +156,7 @@ struct af_alg_ctx { struct af_alg_completion completion; size_t used; - size_t rcvused; + atomic_t rcvused; bool more; bool merge; @@ -228,7 +229,7 @@ static inline int af_alg_rcvbuf(struct s struct af_alg_ctx *ctx = ask->private; return max_t(int, max_t(int, sk->sk_rcvbuf & PAGE_MASK, PAGE_SIZE) - - ctx->rcvused, 0); + atomic_read(&ctx->rcvused), 0); } /** Patches currently in stable-queue which might be from Jonathan.Cameron(a)huawei.com are queue-4.14/crypto-af_alg-fix-race-around-ctx-rcvused-by-making-it-atomic_t.patch

7 years, 4 months

1
0
0 0

Patch "cgroup: Fix deadlock in cpu hotplug path" 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 cgroup: Fix deadlock in cpu hotplug path 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: cgroup-fix-deadlock-in-cpu-hotplug-path.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Wed Feb 28 16:23:28 CET 2018 From: Prateek Sood <prsood(a)codeaurora.org> Date: Tue, 19 Dec 2017 12:56:57 +0530 Subject: cgroup: Fix deadlock in cpu hotplug path From: Prateek Sood <prsood(a)codeaurora.org> [ Upstream commit 116d2f7496c51b2e02e8e4ecdd2bdf5fb9d5a641 ] Deadlock during cgroup migration from cpu hotplug path when a task T is being moved from source to destination cgroup. kworker/0:0 cpuset_hotplug_workfn() cpuset_hotplug_update_tasks() hotplug_update_tasks_legacy() remove_tasks_in_empty_cpuset() cgroup_transfer_tasks() // stuck in iterator loop cgroup_migrate() cgroup_migrate_add_task() In cgroup_migrate_add_task() it checks for PF_EXITING flag of task T. Task T will not migrate to destination cgroup. css_task_iter_start() will keep pointing to task T in loop waiting for task T cg_list node to be removed. Task T do_exit() exit_signals() // sets PF_EXITING exit_task_namespaces() switch_task_namespaces() free_nsproxy() put_mnt_ns() drop_collected_mounts() namespace_unlock() synchronize_rcu() _synchronize_rcu_expedited() schedule_work() // on cpu0 low priority worker pool wait_event() // waiting for work item to execute Task T inserted a work item in the worklist of cpu0 low priority worker pool. It is waiting for expedited grace period work item to execute. This work item will only be executed once kworker/0:0 complete execution of cpuset_hotplug_workfn(). kworker/0:0 ==> Task T ==>kworker/0:0 In case of PF_EXITING task being migrated from source to destination cgroup, migrate next available task in source cgroup. Signed-off-by: Prateek Sood <prsood(a)codeaurora.org> Signed-off-by: Tejun Heo <tj(a)kernel.org> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- kernel/cgroup/cgroup-v1.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) --- a/kernel/cgroup/cgroup-v1.c +++ b/kernel/cgroup/cgroup-v1.c @@ -123,7 +123,11 @@ int cgroup_transfer_tasks(struct cgroup */ do { css_task_iter_start(&from->self, 0, &it); - task = css_task_iter_next(&it); + + do { + task = css_task_iter_next(&it); + } while (task && (task->flags & PF_EXITING)); + if (task) get_task_struct(task); css_task_iter_end(&it); Patches currently in stable-queue which might be from prsood(a)codeaurora.org are queue-4.14/cgroup-fix-deadlock-in-cpu-hotplug-path.patch

7 years, 4 months

1
0
0 0

Patch "can: flex_can: Correct the checking for frame length in flexcan_start_xmit()" 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 can: flex_can: Correct the checking for frame length in flexcan_start_xmit() 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: can-flex_can-correct-the-checking-for-frame-length-in-flexcan_start_xmit.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Wed Feb 28 16:23:28 CET 2018 From: Luu An Phu <phu.luuan(a)nxp.com> Date: Tue, 2 Jan 2018 10:44:18 +0700 Subject: can: flex_can: Correct the checking for frame length in flexcan_start_xmit() From: Luu An Phu <phu.luuan(a)nxp.com> [ Upstream commit 13454c14550065fcc1705d6bd4ee6d40e057099f ] The flexcan_start_xmit() function compares the frame length with data register length to write frame content into data[0] and data[1] register. Data register length is 4 bytes and frame maximum length is 8 bytes. Fix the check that compares frame length with 3. Because the register length is 4. Signed-off-by: Luu An Phu <phu.luuan(a)nxp.com> Reviewed-by: Oliver Hartkopp <socketcan(a)hartkopp.net> Signed-off-by: Marc Kleine-Budde <mkl(a)pengutronix.de> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/can/flexcan.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/net/can/flexcan.c +++ b/drivers/net/can/flexcan.c @@ -526,7 +526,7 @@ static int flexcan_start_xmit(struct sk_ data = be32_to_cpup((__be32 *)&cf->data[0]); flexcan_write(data, &priv->tx_mb->data[0]); } - if (cf->can_dlc > 3) { + if (cf->can_dlc > 4) { data = be32_to_cpup((__be32 *)&cf->data[4]); flexcan_write(data, &priv->tx_mb->data[1]); } Patches currently in stable-queue which might be from phu.luuan(a)nxp.com are queue-4.14/can-flex_can-correct-the-checking-for-frame-length-in-flexcan_start_xmit.patch

7 years, 4 months

1
0
0 0

Patch "btrfs: Fix flush bio leak" 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 btrfs: Fix flush bio leak 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: btrfs-fix-flush-bio-leak.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Wed Feb 28 16:23:28 CET 2018 From: Nikolay Borisov <nborisov(a)suse.com> Date: Wed, 13 Dec 2017 13:50:07 +0200 Subject: btrfs: Fix flush bio leak From: Nikolay Borisov <nborisov(a)suse.com> [ Upstream commit beed9263f4000c48a5c48912f26576f6fa091181 ] Commit e0ae99941423 ("btrfs: preallocate device flush bio") reworked the way the flush bio is allocated and used. Concretely it allocates the bio in __alloc_device and then re-uses it multiple times with a very simple endio routine that just calls complete() without consuming a reference. Allocated bios by default come with a ref count of 1, which is then consumed by the endio routine (or not, in which case they should be bio_put by the caller). The way the impleementation works now is that the flush bio has a refcount of 2 and we only ever bio_put it once, leaving it to hang indefinitely. Fix this by removing the extra bio_get in __alloc_device. Fixes: e0ae99941423 ("btrfs: preallocate device flush bio") Signed-off-by: Nikolay Borisov <nborisov(a)suse.com> Reviewed-by: Liu Bo <bo.li.liu(a)oracle.com> Reviewed-by: David Sterba <dsterba(a)suse.com> 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/volumes.c | 1 - 1 file changed, 1 deletion(-) --- a/fs/btrfs/volumes.c +++ b/fs/btrfs/volumes.c @@ -236,7 +236,6 @@ static struct btrfs_device *__alloc_devi kfree(dev); return ERR_PTR(-ENOMEM); } - bio_get(dev->flush_bio); INIT_LIST_HEAD(&dev->dev_list); INIT_LIST_HEAD(&dev->dev_alloc_list); Patches currently in stable-queue which might be from nborisov(a)suse.com are queue-4.14/btrfs-fix-flush-bio-leak.patch

7 years, 4 months

1
0
0 0

Patch "bpf: sockmap missing NULL psock check" 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 bpf: sockmap missing NULL psock check 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: bpf-sockmap-missing-null-psock-check.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Wed Feb 28 16:23:28 CET 2018 From: John Fastabend <john.fastabend(a)gmail.com> Date: Thu, 4 Jan 2018 20:02:09 -0800 Subject: bpf: sockmap missing NULL psock check From: John Fastabend <john.fastabend(a)gmail.com> [ Upstream commit 5731a879d03bdaa00265f8ebc32dfd0e65d25276 ] Add psock NULL check to handle a racing sock event that can get the sk_callback_lock before this case but after xchg happens causing the refcnt to hit zero and sock user data (psock) to be null and queued for garbage collection. Also add a comment in the code because this is a bit subtle and not obvious in my opinion. Signed-off-by: John Fastabend <john.fastabend(a)gmail.com> Signed-off-by: Daniel Borkmann <daniel(a)iogearbox.net> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- kernel/bpf/sockmap.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) --- a/kernel/bpf/sockmap.c +++ b/kernel/bpf/sockmap.c @@ -588,8 +588,15 @@ static void sock_map_free(struct bpf_map write_lock_bh(&sock->sk_callback_lock); psock = smap_psock_sk(sock); - smap_list_remove(psock, &stab->sock_map[i]); - smap_release_sock(psock, sock); + /* This check handles a racing sock event that can get the + * sk_callback_lock before this case but after xchg happens + * causing the refcnt to hit zero and sock user data (psock) + * to be null and queued for garbage collection. + */ + if (likely(psock)) { + smap_list_remove(psock, &stab->sock_map[i]); + smap_release_sock(psock, sock); + } write_unlock_bh(&sock->sk_callback_lock); } rcu_read_unlock(); Patches currently in stable-queue which might be from john.fastabend(a)gmail.com are queue-4.14/bpf-sockmap-missing-null-psock-check.patch

7 years, 4 months

1
0
0 0

Patch "bnxt_en: Fix the 'Invalid VF' id check in bnxt_vf_ndo_prep routine." 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 bnxt_en: Fix the 'Invalid VF' id check in bnxt_vf_ndo_prep routine. 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: bnxt_en-fix-the-invalid-vf-id-check-in-bnxt_vf_ndo_prep-routine.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Wed Feb 28 16:23:28 CET 2018 From: Venkat Duvvuru <venkatkumar.duvvuru(a)broadcom.com> Date: Thu, 4 Jan 2018 18:46:55 -0500 Subject: bnxt_en: Fix the 'Invalid VF' id check in bnxt_vf_ndo_prep routine. From: Venkat Duvvuru <venkatkumar.duvvuru(a)broadcom.com> [ Upstream commit 78f300049335ae81a5cc6b4b232481dc5e1f9d41 ] In bnxt_vf_ndo_prep (which is called by bnxt_get_vf_config ndo), there is a check for "Invalid VF id". Currently, the check is done against max_vfs. However, the user doesn't always create max_vfs. So, the check should be against the created number of VFs. The number of bnxt_vf_info structures that are allocated in bnxt_alloc_vf_resources routine is the "number of requested VFs". So, if an "invalid VF id" falls between the requested number of VFs and the max_vfs, the driver will be dereferencing an invalid pointer. Fixes: c0c050c58d84 ("bnxt_en: New Broadcom ethernet driver.") Signed-off-by: Venkat Devvuru <venkatkumar.duvvuru(a)broadcom.com> 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_sriov.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c +++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c @@ -70,7 +70,7 @@ static int bnxt_vf_ndo_prep(struct bnxt netdev_err(bp->dev, "vf ndo called though sriov is disabled\n"); return -EINVAL; } - if (vf_id >= bp->pf.max_vfs) { + if (vf_id >= bp->pf.active_vfs) { netdev_err(bp->dev, "Invalid VF id %d\n", vf_id); return -EINVAL; } Patches currently in stable-queue which might be from venkatkumar.duvvuru(a)broadcom.com are queue-4.14/bnxt_en-fix-population-of-flow_type-in-bnxt_hwrm_cfa_flow_alloc.patch queue-4.14/bnxt_en-fix-the-invalid-vf-id-check-in-bnxt_vf_ndo_prep-routine.patch

7 years, 4 months

1
0
0 0

[GIT PULL] commits for Linux 4.14

by Sasha Levin

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi Greg, Pleae pull commits for Linux 4.14 . 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 0146985addc322ca518d27fecfe98ae5acda7c1e: Linux 4.14.17 (2018-02-03 17:39:25 +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.14-23022018 for you to fetch changes up to 325a9ccd612b7152566373774adaf6ad8f607e5f: mlxsw: pci: Wait after reset before accessing HW (2018-02-03 12:51:56 -0500) - ---------------------------------------------------------------- for-greg-4.14-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 Andy Shevchenko (1): x86/platform/intel-mid: Revert "Make 'bt_sfi_data' const" Antoine Tenart (2): crypto: inside-secure - free requests even if their handling failed crypto: inside-secure - fix request allocations in invalidation path Arnaldo Carvalho de Melo (1): x86/asm: Allow again using asm.h when building for the 'bpf' clang target Arnd Bergmann (2): exec: avoid gcc-8 warning for get_task_comm ARM: dts: ls1021a: fix incorrect clock references Arvind Yadav (1): phy: cpcap-usb: Fix platform_get_irq_byname's error checking. Bogdan Mirea (1): arm64: dts: renesas: ulcb: Remove renesas, no-ether-link property Boris Ostrovsky (1): xen/balloon: Mark unallocated host memory as UNUSABLE Brendan McGrath (1): ipv6: icmp6: Allow icmp messages to be looped back Bryan Tan (1): RDMA/vmw_pvrdma: Call ib_umem_release on destroy QP path Cathy Avery (1): scsi: storvsc: Fix scsi_cmd error assignments in storvsc_handle_error Christophe JAILLET (2): mm/frame_vector.c: release a semaphore in 'get_vaddr_frames()' 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 Dave Young (1): x86/efi: Fix kernel param add_efi_memmap regression David Howells (1): afs: Fix missing error handling in afs_write_end() Eduardo Otubo (1): xen-netfront: enable device after manual module load Erez Shitrit (1): IB/ipoib: Fix race condition in neigh creation Ewan D. Milne (1): nvme-fabrics: initialize default host->id in nvmf_host_default() Felix Janda (1): uapi libc compat: add fallback for unsupported libcs Florian Westphal (1): netfilter: uapi: correct UNTRACKED conntrack state bit number Fredrik Hallenberg (2): net: stmmac: Fix TX timestamp calculation net: stmmac: Fix bad RX timestamp extraction Gabriel Krisman Bertazi (1): i915: Reject CCS modifiers for pipe C on Geminilake 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 Hangbin Liu (1): netfilter: nf_tables: fix potential NULL-ptr deref in nf_tables_dump_obj_done() Hannes Reinecke (1): scsi: core: check for device state in __scsi_remove_target() Hao Chen (1): nl80211: Check for the required netlink attribute presence Herbert Xu (1): xfrm: Reinject transport-mode packets through tasklet Huy Nguyen (1): net/mlx5e: Fix ETS BW check Igor Russkikh (2): net: aquantia: Fix actual speed capabilities reporting net: aquantia: Fix hardware DMA stream overload on large MRRS Jacek Anaszewski (1): leds: core: Fix regression caused by commit 2b83ff96f51d Jacob Keller (1): i40e: don't remove netdev->dev_addr when syncing uc list Jakub Kicinski (1): nfp: always unmask aux interrupts at init James Hogan (1): lib/mpi: Fix umul_ppmm() for MIPS64r6 James Smart (1): nvme-fc: remove double put reference if admin connect fails Jan Beulich (1): x86-64/Xen: eliminate W+X mappings 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 John David Anglin (1): parisc: Reduce thread stack to 16 kb John Fastabend (1): bpf: sockmap missing NULL psock check John Stultz (1): staging: ion: Fix ion_cma_heap allocations Jonathan Cameron (1): crypto: af_alg - Fix race around ctx->rcvused by making it atomic_t Josh Poimboeuf (1): x86/stacktrace: Make zombie stack traces reliable Karol Herbst (1): drm/nouveau/pci: do a msi rearm on init Keith Busch (1): nvme: check hw sectors before setting chunk sectors Kuninori Morimoto (1): ASoC: rsnd: fixup ADG register mask Lan Tianyu (1): KVM/x86: Check input paging mode when cs.l is set Leon Romanovsky (2): IB/mlx4: Fix mlx4_ib_alloc_mr error flow RDMA/netlink: Fix locking around __ib_get_device_by_index Loic Poulain (1): wcn36xx: Fix dynamic power saving Luu An Phu (1): can: flex_can: Correct the checking for frame length in flexcan_start_xmit() Madalin Bucur (1): of_mdio: avoid MDIO bus removal when a PHY is missing Marcelo Ricardo Leitner (2): sctp: add a ceiling to optlen in some sockopts sctp: make use of pre-calculated len Matthieu CASTET (1): led: core: Fix brightness setting when setting delay_off=0 Michael Ellerman (1): powerpc/pseries: Make RAS IRQ explicitly dependent on DLPAR WQ Ming Lei (1): block: drain queue before waiting for q_usage_counter becoming zero Moshe Shemesh (2): net/mlx5: Cleanup IRQs in case of unload failure net/mlx5: Stay in polling mode when command EQ destroy fails Netanel Belgazal (1): net: ena: unmask MSI-X only after device initialization is completed Nikolay Borisov (1): btrfs: Fix flush bio leak Nitzan Carmi (1): IB/mlx5: Fix mlx5_ib_alloc_mr error flow Ofer Heifetz (1): crypto: inside-secure - per request invalidation Oleksandr Andrushchenko (1): Input: xen-kbdfront - do not advertise multi-touch pressure support Pablo Neira Ayuso (1): netfilter: nf_tables: fix chain filter in nf_tables_dump_rules() Prasad B Munirathnam (1): scsi: aacraid: Fix I/O drop during reset Prateek Sood (1): cgroup: Fix deadlock in cpu hotplug path 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 Russell King (1): net: phy: fix resume handling 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 Sunil Challa (1): bnxt_en: Fix population of flow_type in bnxt_hwrm_cfa_flow_alloc() Tetsuo Handa (1): mm,vmscan: Make unregister_shrinker() no-op if register_shrinker() failed. Thomas Gleixner (1): perf/x86/intel: Plug memory leak in intel_pmu_init() 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 Valentin Ilie (1): ia64, sched/cputime: Fix build error if CONFIG_VIRT_CPU_ACCOUNTING_NATIVE=y Venkat Duvvuru (1): bnxt_en: Fix the 'Invalid VF' id check in bnxt_vf_ndo_prep routine. Xin Long (6): sctp: fix the issue that a __u16 variable may overflow in sctp_ulpq_renege vxlan: update skb dst pmtu on tx path ip_gre: remove the incorrect mtu limit for ipgre tap ip6_gre: remove the incorrect mtu limit for ipgre tap ip6_tunnel: get the min mtu properly in ip6_tnl_xmit ip6_tunnel: allow ip6gre dev mtu to be set below 1280 Xiongwei Song (1): drm/ttm: check the return value of kzalloc Yangbo Lu (1): net: gianfar_ptp: move set_fipers() to spinlock protecting area Yuval Mintz (1): mlxsw: pci: Wait after reset before accessing HW arch/arm/boot/dts/ls1021a-qds.dts | 2 +- arch/arm/boot/dts/ls1021a-twr.dts | 2 +- arch/arm/lib/csumpartialcopyuser.S | 4 + arch/arm64/boot/dts/renesas/ulcb.dtsi | 1 - arch/ia64/kernel/time.c | 2 +- arch/parisc/include/asm/thread_info.h | 5 ++ arch/powerpc/platforms/pseries/dlpar.c | 21 +++++- arch/powerpc/platforms/pseries/pseries.h | 2 + arch/powerpc/platforms/pseries/ras.c | 3 +- arch/sh/boards/mach-se/770x/setup.c | 10 ++- arch/x86/events/intel/core.c | 5 +- arch/x86/include/asm/asm.h | 2 + arch/x86/kernel/setup.c | 5 +- arch/x86/kernel/stacktrace.c | 6 +- arch/x86/kvm/x86.c | 26 +++++++ .../platform/intel-mid/device_libs/platform_bt.c | 2 +- arch/x86/xen/enlighten.c | 81 +++++++++++++++++++++ arch/x86/xen/enlighten_pv.c | 3 + arch/x86/xen/mmu_pv.c | 12 +++ arch/x86/xen/setup.c | 6 +- block/blk-core.c | 9 ++- block/blk-mq.c | 2 + block/blk.h | 2 + crypto/af_alg.c | 4 +- crypto/algif_aead.c | 2 +- crypto/algif_skcipher.c | 2 +- drivers/crypto/inside-secure/safexcel.c | 1 + drivers/crypto/inside-secure/safexcel_cipher.c | 85 +++++++++++++++++----- drivers/crypto/inside-secure/safexcel_hash.c | 79 +++++++++++++++----- drivers/dma/fsl-edma.c | 28 +++---- drivers/gpu/drm/i915/intel_display.c | 2 +- drivers/gpu/drm/nouveau/nvkm/subdev/pci/base.c | 7 ++ drivers/gpu/drm/ttm/ttm_page_alloc.c | 2 + drivers/infiniband/core/core_priv.h | 2 +- drivers/infiniband/core/device.c | 18 ++++- drivers/infiniband/core/nldev.c | 54 +++++++++----- drivers/infiniband/hw/mlx4/mr.c | 2 +- drivers/infiniband/hw/mlx5/mr.c | 1 + drivers/infiniband/hw/vmw_pvrdma/pvrdma_qp.c | 7 ++ drivers/infiniband/ulp/ipoib/ipoib_main.c | 25 +++++-- drivers/infiniband/ulp/ipoib/ipoib_multicast.c | 5 +- drivers/input/misc/xen-kbdfront.c | 2 - drivers/leds/led-core.c | 1 + 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/amazon/ena/ena_netdev.c | 26 +++---- drivers/net/ethernet/aquantia/atlantic/aq_hw.h | 4 +- drivers/net/ethernet/aquantia/atlantic/aq_nic.c | 7 +- drivers/net/ethernet/aquantia/atlantic/aq_nic.h | 2 +- .../net/ethernet/aquantia/atlantic/aq_pci_func.c | 5 +- .../ethernet/aquantia/atlantic/hw_atl/hw_atl_a0.c | 13 +++- .../ethernet/aquantia/atlantic/hw_atl/hw_atl_b0.c | 25 ++++++- .../aquantia/atlantic/hw_atl/hw_atl_llh_internal.h | 6 ++ 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/bnxt/bnxt_tc.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_main.c | 17 ++++- 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 +-- drivers/net/ethernet/mellanox/mlx5/core/en_dcbnl.c | 10 ++- drivers/net/ethernet/mellanox/mlx5/core/eq.c | 18 +++-- drivers/net/ethernet/mellanox/mlxsw/pci.c | 7 +- drivers/net/ethernet/mellanox/mlxsw/pci_hw.h | 1 + .../net/ethernet/netronome/nfp/nfp_net_common.c | 2 + drivers/net/ethernet/stmicro/stmmac/common.h | 2 +- drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c | 5 +- drivers/net/ethernet/stmicro/stmmac/enh_desc.c | 3 +- drivers/net/ethernet/stmicro/stmmac/norm_desc.c | 2 +- .../net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c | 6 +- drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 2 +- drivers/net/macvlan.c | 7 +- drivers/net/phy/at803x.c | 4 - drivers/net/phy/mdio-sun4i.c | 6 +- drivers/net/phy/mdio-xgene.c | 21 ++++-- drivers/net/phy/phy.c | 9 +-- drivers/net/phy/phy_device.c | 10 ++- drivers/net/usb/qmi_wwan.c | 2 + drivers/net/vxlan.c | 14 ++++ drivers/net/wireless/ath/wcn36xx/main.c | 23 +++--- drivers/net/wireless/ath/wcn36xx/pmc.c | 6 +- drivers/net/wireless/mac80211_hwsim.c | 2 +- drivers/net/xen-netfront.c | 1 + drivers/nvme/host/core.c | 3 +- drivers/nvme/host/fabrics.c | 1 + drivers/nvme/host/fc.c | 1 - drivers/of/of_mdio.c | 9 ++- drivers/phy/motorola/phy-cpcap-usb.c | 2 +- drivers/s390/block/dasd_3990_erp.c | 10 +++ drivers/scsi/aacraid/aacraid.h | 1 + drivers/scsi/aacraid/linit.c | 2 +- drivers/scsi/scsi_sysfs.c | 5 +- drivers/scsi/storvsc_drv.c | 3 +- drivers/spi/spi-atmel.c | 2 +- drivers/staging/android/ion/Kconfig | 2 +- drivers/staging/android/ion/ion_cma_heap.c | 15 +++- drivers/xen/balloon.c | 65 ++++++++++++++--- drivers/xen/gntdev.c | 8 +- fs/afs/write.c | 8 +- fs/btrfs/volumes.c | 1 - fs/exec.c | 7 +- fs/super.c | 6 +- fs/xfs/xfs_qm.c | 46 ++++++++---- include/crypto/if_alg.h | 5 +- include/linux/mlx5/driver.h | 2 +- include/linux/sched.h | 6 +- include/net/xfrm.h | 3 + include/uapi/linux/libc-compat.h | 55 +++++++++++++- include/uapi/linux/netfilter/nf_conntrack_common.h | 2 +- include/xen/balloon.h | 5 ++ kernel/bpf/sockmap.c | 11 ++- kernel/cgroup/cgroup-v1.c | 6 +- kernel/irq/debug.h | 5 ++ lib/mpi/longlong.h | 18 ++++- mm/frame_vector.c | 6 +- mm/vmscan.c | 3 + net/ipv4/ip_gre.c | 1 + net/ipv4/xfrm4_input.c | 12 ++- net/ipv6/ip6_gre.c | 1 + net/ipv6/ip6_tunnel.c | 15 ++-- net/ipv6/route.c | 1 + net/ipv6/xfrm6_input.c | 10 ++- net/mac80211/rx.c | 2 + net/netfilter/nf_tables_api.c | 8 +- net/sctp/socket.c | 26 +++++-- net/sctp/ulpqueue.c | 24 ++---- net/tipc/bearer.c | 5 +- net/tipc/monitor.c | 6 +- net/wireless/nl80211.c | 3 +- net/xfrm/xfrm_input.c | 57 +++++++++++++++ sound/soc/codecs/nau8825.c | 1 + sound/soc/sh/rcar/adg.c | 6 +- 140 files changed, 1165 insertions(+), 345 deletions(-) -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJakgpRAAoJEN6mb/eXdyzcm8wP/i0X4jER2p2QUfO7HNKbq1mc GTCqqf/3DalsNaS0VAAg4hWTA1MpzsauARE5IxzADaOcThSxNOQflr8Q8N1Th4QL Ta7aeksQtmS9Jal6kI8wSFJ3ZLKKZUFjTC9eDQmrmDyRj69uzAv4PWPGzVIk5V9E temdeMaygrHF/xAFkuXD/eYFIsSAWiRRhEk1A0M/pr+FoX3Cn6w0+xCBGrE8SJDU 0h87PboerYXiXafou0/jN4o82Vy1ZSntlWd8+c/XvYP4Yijan7M2A4mAV+JLXjxv OzEHMNAXyei5NxmpWms4Q0bnwm0cauK4bxA4HvLaNqVA5V6aKeDImPq8lu5FoKk/ On5QgayNTc1AFUqwp/D+kiiD+HMHwU+qjYYK85GNrNaP7CQryOQ8BLLryjoN9uLZ 8x4T8pWJpv1totIT+MKjq5TIQhBs2wxM4hb7RdcYP6tGndu293W8u6icjgji1ItF rfa/gTODV/uFYuZHqjZ37FEObsi/X8JCwzhHWhiPiKVtgypJN+n93RWJ+glSwllT ftTV91rsH/f+3V8sMPmawszr5cvojB0S/wlMwSNTMZ6QRpj2Gn5QEysVOQGR8iuZ LZ0MUG07kV5w/ZFn/b04iQ8quFMCnOkxo4yW48Lr4OvM7QCu1/vq1P5YLBMv5L3v FxWgZ0TDUS8oOBC6qcNZ =waOz -----END PGP SIGNATURE-----

7 years, 4 months

2
1
0 0

Patch "bnxt_en: Fix population of flow_type in bnxt_hwrm_cfa_flow_alloc()" 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 bnxt_en: Fix population of flow_type in bnxt_hwrm_cfa_flow_alloc() 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: bnxt_en-fix-population-of-flow_type-in-bnxt_hwrm_cfa_flow_alloc.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Wed Feb 28 16:23:28 CET 2018 From: Sunil Challa <sunilkumar.challa(a)broadcom.com> Date: Thu, 4 Jan 2018 18:46:54 -0500 Subject: bnxt_en: Fix population of flow_type in bnxt_hwrm_cfa_flow_alloc() From: Sunil Challa <sunilkumar.challa(a)broadcom.com> [ Upstream commit 7deea450eb912f269d999de62c8ab922d1461748 ] flow_type in HWRM_FLOW_ALLOC is not being populated correctly due to incorrect passing of pointer and size of l3_mask argument of is_wildcard(). Fixed this. Fixes: db1d36a27324 ("bnxt_en: add TC flower offload flow_alloc/free FW cmds") Signed-off-by: Sunil Challa <sunilkumar.challa(a)broadcom.com> Reviewed-by: Sathya Perla <sathya.perla(a)broadcom.com> Reviewed-by: Venkat Duvvuru <venkatkumar.duvvuru(a)broadcom.com> 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_tc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/net/ethernet/broadcom/bnxt/bnxt_tc.c +++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_tc.c @@ -327,7 +327,7 @@ static int bnxt_hwrm_cfa_flow_alloc(stru } /* If all IP and L4 fields are wildcarded then this is an L2 flow */ - if (is_wildcard(&l3_mask, sizeof(l3_mask)) && + if (is_wildcard(l3_mask, sizeof(*l3_mask)) && is_wildcard(&flow->l4_mask, sizeof(flow->l4_mask))) { flow_flags |= CFA_FLOW_ALLOC_REQ_FLAGS_FLOWTYPE_L2; } else { Patches currently in stable-queue which might be from sunilkumar.challa(a)broadcom.com are queue-4.14/bnxt_en-fix-population-of-flow_type-in-bnxt_hwrm_cfa_flow_alloc.patch

7 years, 4 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror