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

Patch "net: cdc_ncm: Fix TX zero padding" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled net: cdc_ncm: Fix TX zero padding to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: net-cdc_ncm-fix-tx-zero-padding.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Apr 9 17:09:24 CEST 2018 From: Jim Baxter <jim_baxter(a)mentor.com> Date: Mon, 8 May 2017 13:49:57 +0100 Subject: net: cdc_ncm: Fix TX zero padding From: Jim Baxter <jim_baxter(a)mentor.com> [ Upstream commit aeca3a77b1e0ed06a095933b89c86aed007383eb ] The zero padding that is added to NTB's does not zero the memory correctly. This is because the skb_put modifies the value of skb_out->len which results in the memset command not setting any memory to zero as (ctx->tx_max - skb_out->len) == 0. I have resolved this by storing the size of the memory to be zeroed before the skb_put and using this in the memset call. Signed-off-by: Jim Baxter <jim_baxter(a)mentor.com> Reviewed-by: Bjørn Mork <bjorn(a)mork.no> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/usb/cdc_ncm.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) --- a/drivers/net/usb/cdc_ncm.c +++ b/drivers/net/usb/cdc_ncm.c @@ -1118,6 +1118,7 @@ cdc_ncm_fill_tx_frame(struct usbnet *dev u16 n = 0, index, ndplen; u8 ready2send = 0; u32 delayed_ndp_size; + size_t padding_count; /* When our NDP gets written in cdc_ncm_ndp(), then skb_out->len gets updated * accordingly. Otherwise, we should check here. @@ -1274,11 +1275,13 @@ cdc_ncm_fill_tx_frame(struct usbnet *dev * a ZLP after full sized NTBs. */ if (!(dev->driver_info->flags & FLAG_SEND_ZLP) && - skb_out->len > ctx->min_tx_pkt) - memset(skb_put(skb_out, ctx->tx_max - skb_out->len), 0, - ctx->tx_max - skb_out->len); - else if (skb_out->len < ctx->tx_max && (skb_out->len % dev->maxpacket) == 0) + skb_out->len > ctx->min_tx_pkt) { + padding_count = ctx->tx_max - skb_out->len; + memset(skb_put(skb_out, padding_count), 0, padding_count); + } else if (skb_out->len < ctx->tx_max && + (skb_out->len % dev->maxpacket) == 0) { *skb_put(skb_out, 1) = 0; /* force short packet */ + } /* set final frame length */ nth16 = (struct usb_cdc_ncm_nth16 *)skb_out->data; Patches currently in stable-queue which might be from jim_baxter(a)mentor.com are queue-4.9/net-cdc_ncm-fix-tx-zero-padding.patch

7 years, 7 months

1
0
0 0

Patch "neighbour: update neigh timestamps iff update is effective" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled neighbour: update neigh timestamps iff update is effective to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: neighbour-update-neigh-timestamps-iff-update-is-effective.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Apr 9 17:09:24 CEST 2018 From: Ihar Hrachyshka <ihrachys(a)redhat.com> Date: Tue, 16 May 2017 08:44:24 -0700 Subject: neighbour: update neigh timestamps iff update is effective From: Ihar Hrachyshka <ihrachys(a)redhat.com> [ Upstream commit 77d7123342dcf6442341b67816321d71da8b2b16 ] It's a common practice to send gratuitous ARPs after moving an IP address to another device to speed up healing of a service. To fulfill service availability constraints, the timing of network peers updating their caches to point to a new location of an IP address can be particularly important. Sometimes neigh_update calls won't touch neither lladdr nor state, for example if an update arrives in locktime interval. The neigh->updated value is tested by the protocol specific neigh code, which in turn will influence whether NEIGH_UPDATE_F_OVERRIDE gets set in the call to neigh_update() or not. As a result, we may effectively ignore the update request, bailing out of touching the neigh entry, except that we still bump its timestamps inside neigh_update. This may be a problem for updates arriving in quick succession. For example, consider the following scenario: A service is moved to another device with its IP address. The new device sends three gratuitous ARP requests into the network with ~1 seconds interval between them. Just before the first request arrives to one of network peer nodes, its neigh entry for the IP address transitions from STALE to DELAY. This transition, among other things, updates neigh->updated. Once the kernel receives the first gratuitous ARP, it ignores it because its arrival time is inside the locktime interval. The kernel still bumps neigh->updated. Then the second gratuitous ARP request arrives, and it's also ignored because it's still in the (new) locktime interval. Same happens for the third request. The node eventually heals itself (after delay_first_probe_time seconds since the initial transition to DELAY state), but it just wasted some time and require a new ARP request/reply round trip. This unfortunate behaviour both puts more load on the network, as well as reduces service availability. This patch changes neigh_update so that it bumps neigh->updated (as well as neigh->confirmed) only once we are sure that either lladdr or entry state will change). In the scenario described above, it means that the second gratuitous ARP request will actually update the entry lladdr. Ideally, we would update the neigh entry on the very first gratuitous ARP request. The locktime mechanism is designed to ignore ARP updates in a short timeframe after a previous ARP update was honoured by the kernel layer. This would require tracking timestamps for state transitions separately from timestamps when actual updates are received. This would probably involve changes in neighbour struct. Therefore, the patch doesn't tackle the issue of the first gratuitous APR ignored, leaving it for a follow-up. Signed-off-by: Ihar Hrachyshka <ihrachys(a)redhat.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/core/neighbour.c | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-) --- a/net/core/neighbour.c +++ b/net/core/neighbour.c @@ -1130,10 +1130,6 @@ int neigh_update(struct neighbour *neigh lladdr = neigh->ha; } - if (new & NUD_CONNECTED) - neigh->confirmed = jiffies; - neigh->updated = jiffies; - /* If entry was valid and address is not changed, do not change entry state, if new one is STALE. */ @@ -1155,6 +1151,16 @@ int neigh_update(struct neighbour *neigh } } + /* Update timestamps only once we know we will make a change to the + * neighbour entry. Otherwise we risk to move the locktime window with + * noop updates and ignore relevant ARP updates. + */ + if (new != old || lladdr != neigh->ha) { + if (new & NUD_CONNECTED) + neigh->confirmed = jiffies; + neigh->updated = jiffies; + } + if (new != old) { neigh_del_timer(neigh); if (new & NUD_PROBE) Patches currently in stable-queue which might be from ihrachys(a)redhat.com are queue-4.9/arp-honour-gratuitous-arp-_replies_.patch queue-4.9/neighbour-update-neigh-timestamps-iff-update-is-effective.patch

7 years, 7 months

1
0
0 0

Patch "mtd: nand: gpmi: Fix gpmi_nand_init() error path" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled mtd: nand: gpmi: Fix gpmi_nand_init() error path to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: mtd-nand-gpmi-fix-gpmi_nand_init-error-path.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Apr 9 17:09:24 CEST 2018 From: Boris Brezillon <boris.brezillon(a)free-electrons.com> Date: Mon, 10 Apr 2017 10:35:17 +0200 Subject: mtd: nand: gpmi: Fix gpmi_nand_init() error path From: Boris Brezillon <boris.brezillon(a)free-electrons.com> [ Upstream commit 4d02423e9afe6c46142ce98bbcaf5167316dbfbf ] The GPMI driver is wrongly assuming that nand_release() can safely be called on an uninitialized/unregistered NAND device. Add a new err_nand_cleanup label in the error path and only execute if nand_scan_tail() succeeded. Note that we now call nand_cleanup() instead of nand_release() (nand_release() is actually grouping the mtd_device_unregister() and nand_cleanup() in one call) because there's no point in trying to unregister a device that has never been registered. Signed-off-by: Boris Brezillon <boris.brezillon(a)free-electrons.com> Reviewed-by: Marek Vasut <marek.vasut(a)gmail.com> Acked-by: Han Xu <han.xu(a)nxp.com> Reviewed-by: Marek Vasut <marek.vasut(a)gmail.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/mtd/nand/gpmi-nand/gpmi-nand.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) --- a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c +++ b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c @@ -2047,18 +2047,20 @@ static int gpmi_nand_init(struct gpmi_na ret = nand_boot_init(this); if (ret) - goto err_out; + goto err_nand_cleanup; ret = chip->scan_bbt(mtd); if (ret) - goto err_out; + goto err_nand_cleanup; ret = mtd_device_register(mtd, NULL, 0); if (ret) - goto err_out; + goto err_nand_cleanup; return 0; +err_nand_cleanup: + nand_cleanup(chip); err_out: - gpmi_nand_exit(this); + gpmi_free_dma_buffer(this); return ret; } Patches currently in stable-queue which might be from boris.brezillon(a)free-electrons.com are queue-4.9/mtd-nand-gpmi-fix-gpmi_nand_init-error-path.patch queue-4.9/mtd-mtd_oobtest-handle-bitflips-during-reads.patch queue-4.9/mtd-nand-check-ecc-total-sanity-in-nand_scan_tail.patch

7 years, 7 months

1
0
0 0

Patch "mtd: mtd_oobtest: Handle bitflips during reads" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled mtd: mtd_oobtest: Handle bitflips during reads to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: mtd-mtd_oobtest-handle-bitflips-during-reads.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Apr 9 17:09:24 CEST 2018 From: Miquel Raynal <miquel.raynal(a)free-electrons.com> Date: Thu, 11 Jan 2018 21:39:20 +0100 Subject: mtd: mtd_oobtest: Handle bitflips during reads From: Miquel Raynal <miquel.raynal(a)free-electrons.com> [ Upstream commit 12663b442e5ac5aa3d6097cd3f287c71ba46d26e ] Reads from NAND devices usually trigger bitflips, this is an expected behavior. While bitflips are under a given threshold, the MTD core returns 0. However, when the number of corrected bitflips is above this same threshold, -EUCLEAN is returned to inform the upper layer that this block is slightly dying and soon the ECC engine will be overtaken so actions should be taken to move the data out of it. This particular condition should not be treated like an error and the test should continue. Signed-off-by: Miquel Raynal <miquel.raynal(a)free-electrons.com> Signed-off-by: Boris Brezillon <boris.brezillon(a)free-electrons.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/mtd/tests/oobtest.c | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) --- a/drivers/mtd/tests/oobtest.c +++ b/drivers/mtd/tests/oobtest.c @@ -193,6 +193,9 @@ static int verify_eraseblock(int ebnum) ops.datbuf = NULL; ops.oobbuf = readbuf; err = mtd_read_oob(mtd, addr, &ops); + if (mtd_is_bitflip(err)) + err = 0; + if (err || ops.oobretlen != use_len) { pr_err("error: readoob failed at %#llx\n", (long long)addr); @@ -227,6 +230,9 @@ static int verify_eraseblock(int ebnum) ops.datbuf = NULL; ops.oobbuf = readbuf; err = mtd_read_oob(mtd, addr, &ops); + if (mtd_is_bitflip(err)) + err = 0; + if (err || ops.oobretlen != mtd->oobavail) { pr_err("error: readoob failed at %#llx\n", (long long)addr); @@ -286,6 +292,9 @@ static int verify_eraseblock_in_one_go(i /* read entire block's OOB at one go */ err = mtd_read_oob(mtd, addr, &ops); + if (mtd_is_bitflip(err)) + err = 0; + if (err || ops.oobretlen != len) { pr_err("error: readoob failed at %#llx\n", (long long)addr); @@ -527,6 +536,9 @@ static int __init mtd_oobtest_init(void) pr_info("attempting to start read past end of OOB\n"); pr_info("an error is expected...\n"); err = mtd_read_oob(mtd, addr0, &ops); + if (mtd_is_bitflip(err)) + err = 0; + if (err) { pr_info("error occurred as expected\n"); err = 0; @@ -571,6 +583,9 @@ static int __init mtd_oobtest_init(void) pr_info("attempting to read past end of device\n"); pr_info("an error is expected...\n"); err = mtd_read_oob(mtd, mtd->size - mtd->writesize, &ops); + if (mtd_is_bitflip(err)) + err = 0; + if (err) { pr_info("error occurred as expected\n"); err = 0; @@ -615,6 +630,9 @@ static int __init mtd_oobtest_init(void) pr_info("attempting to read past end of device\n"); pr_info("an error is expected...\n"); err = mtd_read_oob(mtd, mtd->size - mtd->writesize, &ops); + if (mtd_is_bitflip(err)) + err = 0; + if (err) { pr_info("error occurred as expected\n"); err = 0; @@ -684,6 +702,9 @@ static int __init mtd_oobtest_init(void) ops.datbuf = NULL; ops.oobbuf = readbuf; err = mtd_read_oob(mtd, addr, &ops); + if (mtd_is_bitflip(err)) + err = 0; + if (err) goto out; if (memcmpshow(addr, readbuf, writebuf, Patches currently in stable-queue which might be from miquel.raynal(a)free-electrons.com are queue-4.9/mtd-mtd_oobtest-handle-bitflips-during-reads.patch

7 years, 7 months

1
0
0 0

Patch "mtd: nand: check ecc->total sanity in nand_scan_tail" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled mtd: nand: check ecc->total sanity in nand_scan_tail to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: mtd-nand-check-ecc-total-sanity-in-nand_scan_tail.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Apr 9 17:09:24 CEST 2018 From: Masahiro Yamada <yamada.masahiro(a)socionext.com> Date: Thu, 25 May 2017 13:50:20 +0900 Subject: mtd: nand: check ecc->total sanity in nand_scan_tail From: Masahiro Yamada <yamada.masahiro(a)socionext.com> [ Upstream commit 79e0348c4e24fd1affdcf055e0269755580e0fcc ] Drivers are supposed to set correct ecc->{size,strength,bytes} before calling nand_scan_tail(), but it does not complain about ecc->total bigger than oobsize. In this case, chip->scan_bbt() crashes due to memory corruption, but it is hard to debug. It would be kind to fail it earlier with a clear message. Signed-off-by: Masahiro Yamada <yamada.masahiro(a)socionext.com> Signed-off-by: Boris Brezillon <boris.brezillon(a)free-electrons.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/mtd/nand/nand_base.c | 5 +++++ 1 file changed, 5 insertions(+) --- a/drivers/mtd/nand/nand_base.c +++ b/drivers/mtd/nand/nand_base.c @@ -4785,6 +4785,11 @@ int nand_scan_tail(struct mtd_info *mtd) goto err_free; } ecc->total = ecc->steps * ecc->bytes; + if (ecc->total > mtd->oobsize) { + WARN(1, "Total number of ECC bytes exceeded oobsize\n"); + ret = -EINVAL; + goto err_free; + } /* * The number of bytes available for a client to place data into Patches currently in stable-queue which might be from yamada.masahiro(a)socionext.com are queue-4.9/tags-honor-compiled_source-with-apart-output-directory.patch queue-4.9/drivers-misc-vmw_vmci-vmci_queue_pair.c-fix-a-couple-integer-overflow-tests.patch queue-4.9/mtd-nand-check-ecc-total-sanity-in-nand_scan_tail.patch

7 years, 7 months

1
0
0 0

Patch "mm, vmstat: Remove spurious WARN() during zoneinfo print" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled mm, vmstat: Remove spurious WARN() during zoneinfo print to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: mm-vmstat-remove-spurious-warn-during-zoneinfo-print.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Apr 9 17:09:24 CEST 2018 From: Reza Arbab <arbab(a)linux.vnet.ibm.com> Date: Fri, 12 May 2017 15:46:32 -0700 Subject: mm, vmstat: Remove spurious WARN() during zoneinfo print From: Reza Arbab <arbab(a)linux.vnet.ibm.com> [ Upstream commit 8d35bb310698c69d73073b26fc581f2e3f7f621d ] After commit e2ecc8a79ed4 ("mm, vmstat: print non-populated zones in zoneinfo"), /proc/zoneinfo will show unpopulated zones. A memoryless node, having no populated zones at all, was previously ignored, but will now trigger the WARN() in is_zone_first_populated(). Remove this warning, as its only purpose was to warn of a situation that has since been enabled. Aside: The "per-node stats" are still printed under the first populated zone, but that's not necessarily the first stanza any more. I'm not sure which criteria is more important with regard to not breaking parsers, but it looks a little weird to the eye. Fixes: e2ecc8a79ed4 ("mm, vmstat: print node-based stats in zoneinfo file") Link: http://lkml.kernel.org/r/1493854905-10918-1-git-send-email-arbab@linux.vnet… Signed-off-by: Reza Arbab <arbab(a)linux.vnet.ibm.com> Cc: David Rientjes <rientjes(a)google.com> Cc: Anshuman Khandual <khandual(a)linux.vnet.ibm.com> Cc: Vlastimil Babka <vbabka(a)suse.cz> Cc: Mel Gorman <mgorman(a)techsingularity.net> Cc: Johannes Weiner <hannes(a)cmpxchg.org> 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)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- mm/vmstat.c | 2 -- 1 file changed, 2 deletions(-) --- a/mm/vmstat.c +++ b/mm/vmstat.c @@ -1351,8 +1351,6 @@ static bool is_zone_first_populated(pg_d return zone == compare; } - /* The zone must be somewhere! */ - WARN_ON_ONCE(1); return false; } Patches currently in stable-queue which might be from arbab(a)linux.vnet.ibm.com are queue-4.9/mm-vmstat-remove-spurious-warn-during-zoneinfo-print.patch

7 years, 7 months

1
0
0 0

Patch "mlxsw: spectrum: Avoid possible NULL pointer dereference" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled mlxsw: spectrum: Avoid possible NULL pointer dereference to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: mlxsw-spectrum-avoid-possible-null-pointer-dereference.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Apr 9 17:09:24 CEST 2018 From: Ido Schimmel <idosch(a)mellanox.com> Date: Thu, 18 May 2017 13:03:52 +0200 Subject: mlxsw: spectrum: Avoid possible NULL pointer dereference From: Ido Schimmel <idosch(a)mellanox.com> [ Upstream commit c0e01eac7ada785fdeaea1ae5476ec1cf3b00374 ] In case we got an FDB notification for a port that doesn't exist we execute an FDB entry delete to prevent it from re-appearing the next time we poll for notifications. If the operation failed we would trigger a NULL pointer dereference as 'mlxsw_sp_port' is NULL. Fix it by reporting the error using the underlying bus device instead. Fixes: 12f1501e7511 ("mlxsw: spectrum: remove FDB entry in case we get unknown object notification") Signed-off-by: Ido Schimmel <idosch(a)mellanox.com> Signed-off-by: Jiri Pirko <jiri(a)mellanox.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) --- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c +++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c @@ -1448,8 +1448,7 @@ do_fdb_op: err = mlxsw_sp_port_fdb_uc_op(mlxsw_sp, local_port, mac, fid, adding, true); if (err) { - if (net_ratelimit()) - netdev_err(mlxsw_sp_port->dev, "Failed to set FDB entry\n"); + dev_err_ratelimited(mlxsw_sp->bus_info->dev, "Failed to set FDB entry\n"); return; } @@ -1509,8 +1508,7 @@ do_fdb_op: err = mlxsw_sp_port_fdb_uc_lag_op(mlxsw_sp, lag_id, mac, fid, lag_vid, adding, true); if (err) { - if (net_ratelimit()) - netdev_err(mlxsw_sp_port->dev, "Failed to set FDB entry\n"); + dev_err_ratelimited(mlxsw_sp->bus_info->dev, "Failed to set FDB entry\n"); return; } Patches currently in stable-queue which might be from idosch(a)mellanox.com are queue-4.9/mlxsw-spectrum-avoid-possible-null-pointer-dereference.patch

7 years, 7 months

1
0
0 0

Patch "mlx5: fix bug reading rss_hash_type from CQE" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled mlx5: fix bug reading rss_hash_type from CQE to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: mlx5-fix-bug-reading-rss_hash_type-from-cqe.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Apr 9 17:09:24 CEST 2018 From: Jesper Dangaard Brouer <brouer(a)redhat.com> Date: Mon, 22 May 2017 20:13:07 +0200 Subject: mlx5: fix bug reading rss_hash_type from CQE From: Jesper Dangaard Brouer <brouer(a)redhat.com> [ Upstream commit 12e8b570e732eaa5eae3a2895ba3fbcf91bde2b4 ] Masks for extracting part of the Completion Queue Entry (CQE) field rss_hash_type was swapped, namely CQE_RSS_HTYPE_IP and CQE_RSS_HTYPE_L4. The bug resulted in setting skb->l4_hash, even-though the rss_hash_type indicated that hash was NOT computed over the L4 (UDP or TCP) part of the packet. Added comments from the datasheet, to make it more clear what these masks are selecting. Signed-off-by: Jesper Dangaard Brouer <brouer(a)redhat.com> Acked-by: Saeed Mahameed <saeedm(a)mellanox.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- include/linux/mlx5/device.h | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) --- a/include/linux/mlx5/device.h +++ b/include/linux/mlx5/device.h @@ -750,8 +750,14 @@ enum { }; enum { - CQE_RSS_HTYPE_IP = 0x3 << 6, - CQE_RSS_HTYPE_L4 = 0x3 << 2, + CQE_RSS_HTYPE_IP = 0x3 << 2, + /* cqe->rss_hash_type[3:2] - IP destination selected for hash + * (00 = none, 01 = IPv4, 10 = IPv6, 11 = Reserved) + */ + CQE_RSS_HTYPE_L4 = 0x3 << 6, + /* cqe->rss_hash_type[7:6] - L4 destination selected for hash + * (00 = none, 01 = TCP. 10 = UDP, 11 = IPSEC.SPI + */ }; enum { Patches currently in stable-queue which might be from brouer(a)redhat.com are queue-4.9/mlx5-fix-bug-reading-rss_hash_type-from-cqe.patch

7 years, 7 months

1
0
0 0

Patch "mISDN: Fix a sleep-in-atomic bug" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled mISDN: Fix a sleep-in-atomic bug to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: misdn-fix-a-sleep-in-atomic-bug.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Apr 9 17:09:24 CEST 2018 From: Jia-Ju Bai <baijiaju1990(a)163.com> Date: Wed, 31 May 2017 15:08:25 +0800 Subject: mISDN: Fix a sleep-in-atomic bug From: Jia-Ju Bai <baijiaju1990(a)163.com> [ Upstream commit 93818da5eed63fbc17b64080406ea53b86b23309 ] The driver may sleep under a read spin lock, and the function call path is: send_socklist (acquire the lock by read_lock) skb_copy(GFP_KERNEL) --> may sleep To fix it, the "GFP_KERNEL" is replaced with "GFP_ATOMIC". Signed-off-by: Jia-Ju Bai <baijiaju1990(a)163.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/isdn/mISDN/stack.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/isdn/mISDN/stack.c +++ b/drivers/isdn/mISDN/stack.c @@ -72,7 +72,7 @@ send_socklist(struct mISDN_sock_list *sl if (sk->sk_state != MISDN_BOUND) continue; if (!cskb) - cskb = skb_copy(skb, GFP_KERNEL); + cskb = skb_copy(skb, GFP_ATOMIC); if (!cskb) { printk(KERN_WARNING "%s no skb\n", __func__); break; Patches currently in stable-queue which might be from baijiaju1990(a)163.com are queue-4.9/misdn-fix-a-sleep-in-atomic-bug.patch queue-4.9/qlcnic-fix-a-sleep-in-atomic-bug-in-qlcnic_82xx_hw_write_wx_2m-and-qlcnic_82xx_hw_read_wx_2m.patch

7 years, 7 months

1
0
0 0

Patch "MIPS: mm: fixed mappings: correct initialisation" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled MIPS: mm: fixed mappings: correct initialisation to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: mips-mm-fixed-mappings-correct-initialisation.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Apr 9 17:09:24 CEST 2018 From: Marcin Nowakowski <marcin.nowakowski(a)imgtec.com> Date: Tue, 11 Apr 2017 09:00:34 +0200 Subject: MIPS: mm: fixed mappings: correct initialisation From: Marcin Nowakowski <marcin.nowakowski(a)imgtec.com> [ Upstream commit 71eb989ab5a110df8bcbb9609bacde73feacbedd ] fixrange_init operates at PMD-granularity and expects the addresses to be PMD-size aligned, but currently that might not be the case for PKMAP_BASE unless it is defined properly, so ensure a correct alignment is used before passing the address to fixrange_init. fixed mappings: only align the start address that is passed to fixrange_init rather than the value before adding the size, as we may end up with uninitialised upper part of the range. Signed-off-by: Marcin Nowakowski <marcin.nowakowski(a)imgtec.com> Cc: linux-mips(a)linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/15948/ Signed-off-by: Ralf Baechle <ralf(a)linux-mips.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/mips/mm/pgtable-32.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) --- a/arch/mips/mm/pgtable-32.c +++ b/arch/mips/mm/pgtable-32.c @@ -51,15 +51,15 @@ void __init pagetable_init(void) /* * Fixed mappings: */ - vaddr = __fix_to_virt(__end_of_fixed_addresses - 1) & PMD_MASK; - fixrange_init(vaddr, vaddr + FIXADDR_SIZE, pgd_base); + vaddr = __fix_to_virt(__end_of_fixed_addresses - 1); + fixrange_init(vaddr & PMD_MASK, vaddr + FIXADDR_SIZE, pgd_base); #ifdef CONFIG_HIGHMEM /* * Permanent kmaps: */ vaddr = PKMAP_BASE; - fixrange_init(vaddr, vaddr + PAGE_SIZE*LAST_PKMAP, pgd_base); + fixrange_init(vaddr & PMD_MASK, vaddr + PAGE_SIZE*LAST_PKMAP, pgd_base); pgd = swapper_pg_dir + __pgd_offset(vaddr); pud = pud_offset(pgd, vaddr); Patches currently in stable-queue which might be from marcin.nowakowski(a)imgtec.com are queue-4.9/mips-mm-fixed-mappings-correct-initialisation.patch queue-4.9/mips-mm-adjust-pkmap-location.patch queue-4.9/mips-kprobes-flush_insn_slot-should-flush-only-if-probe-initialised.patch

7 years, 7 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror