From: Shirish Pargaonkar <shirishpargaonkar(a)gmail.com>
Validate_buf () function checks for an expected minimum sized response
passed to query_info() function.
For security information, the size of a security descriptor can be
smaller (one subauthority, no ACEs) than the size of the structure
that defines FileInfoClass of FileAllInformation.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=199725
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Shirish Pargaonkar <shirishpargaonkar(a)gmail.com>
Signed-off-by: Noah Morrison <noah.morrison(a)rubrik.com>
---
fs/cifs/cifsacl.h | 14 ++++++++++++++
fs/cifs/smb2pdu.c | 3 +--
2 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/fs/cifs/cifsacl.h b/fs/cifs/cifsacl.h
index 4f38848..dd95a6f 100644
--- a/fs/cifs/cifsacl.h
+++ b/fs/cifs/cifsacl.h
@@ -98,4 +98,18 @@ struct cifs_ace {
struct cifs_sid sid; /* ie UUID of user or group who gets these perms */
} __attribute__((packed));
+/*
+ * Minimum security identifier can be one for system defined Users
+ * and Groups such as NULL SID and World or Built-in accounts such
+ * as Administrator and Guest and consists of
+ * Revision + Num (Sub)Auths + Authority + Domain (one Subauthority)
+ */
+#define MIN_SID_LEN (1 + 1 + 6 + 4) /* in bytes */
+
+/*
+ * Minimum security descriptor can be one without any SACL and DACL and can
+ * consist of revision, type, and two sids of minimum size for owner and group
+ */
+#define MIN_SEC_DESC_LEN (sizeof(struct cifs_ntsd) + (2 * MIN_SID_LEN))
+
#endif /* _CIFSACL_H */
diff --git a/fs/cifs/smb2pdu.c b/fs/cifs/smb2pdu.c
index 60db51b..47538a4 100644
--- a/fs/cifs/smb2pdu.c
+++ b/fs/cifs/smb2pdu.c
@@ -2374,8 +2374,7 @@ int SMB2_query_info(const unsigned int xid, struct cifs_tcon *tcon,
return query_info(xid, tcon, persistent_fid, volatile_fid,
0, SMB2_O_INFO_SECURITY, additional_info,
- SMB2_MAX_BUFFER_SIZE,
- sizeof(struct smb2_file_all_info), data, plen);
+ SMB2_MAX_BUFFER_SIZE, MIN_SEC_DESC_LEN, data, plen);
}
int
--
1.9.1
"qxl_bo_unref" may sleep, but calling "qxl_release_map" causes
"preempt_disable()" to be called and "preempt_enable()" isn't called
until "qxl_release_unmap" is used. Move the call to "qxl_bo_unref" out
from in between the two to avoid sleeping from an atomic context.
This issue can be demonstrated on a kernel with CONFIG_LOCKDEP=y by
creating a VM using QXL, using a desktop environment using Xorg, then
moving the cursor on or off a window.
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1571128
Fixes: 9428088c90b6 ("drm/qxl: reapply cursor after resetting primary")
Cc: stable(a)vger.kernel.org
Signed-off-by: Jeremy Cline <jcline(a)redhat.com>
---
drivers/gpu/drm/qxl/qxl_display.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_display.c b/drivers/gpu/drm/qxl/qxl_display.c
index ecb35ed0eac8..61e51516fec5 100644
--- a/drivers/gpu/drm/qxl/qxl_display.c
+++ b/drivers/gpu/drm/qxl/qxl_display.c
@@ -630,7 +630,7 @@ static void qxl_cursor_atomic_update(struct drm_plane *plane,
struct qxl_cursor_cmd *cmd;
struct qxl_cursor *cursor;
struct drm_gem_object *obj;
- struct qxl_bo *cursor_bo = NULL, *user_bo = NULL;
+ struct qxl_bo *cursor_bo = NULL, *user_bo = NULL, *old_cursor_bo = NULL;
int ret;
void *user_ptr;
int size = 64*64*4;
@@ -684,7 +684,7 @@ static void qxl_cursor_atomic_update(struct drm_plane *plane,
cursor_bo, 0);
cmd->type = QXL_CURSOR_SET;
- qxl_bo_unref(&qcrtc->cursor_bo);
+ old_cursor_bo = qcrtc->cursor_bo;
qcrtc->cursor_bo = cursor_bo;
cursor_bo = NULL;
} else {
@@ -704,6 +704,9 @@ static void qxl_cursor_atomic_update(struct drm_plane *plane,
qxl_push_cursor_ring_release(qdev, release, QXL_CMD_CURSOR, false);
qxl_release_fence_buffer_objects(release);
+ if (old_cursor_bo)
+ qxl_bo_unref(&old_cursor_bo);
+
qxl_bo_unref(&cursor_bo);
return;
--
2.17.0
Please add 4.17 commit 145e1a71e090575c74969e3daa8136d1e5b99fc8
("mm: fix the NULL mapping case in __isolate_lru_page()")
to the 4.16, 4.14, 4.9, 4.4, 3.18 and 3.2 stable kernel trees.
Two things happened after I'd sent it to Andrew without a stable tag:
1. Ivan posted an equivalent patch: after painstaking bisection, he
had found the fixed commit to be what was causing strange blocking
(surprising to the rest of us, we had imagined it just suboptimal).
2. The fixed commit arrived in five stable kernel releases (presumably
arriving there by auto selection: which will in due course pick up
this fix to it, but I don't know its cadence).
Thanks,
Hugh
From: Hugh Dickins <hughd(a)google.com>
Date: Fri, 1 Jun 2018 16:50:50 -0700
George Boole would have noticed a slight error in 4.16 commit
69d763fc6d3a ("mm: pin address_space before dereferencing it while
isolating an LRU page"). Fix it, to match both the comment above it,
and the original behaviour.
Although anonymous pages are not marked PageDirty at first, we have an
old habit of calling SetPageDirty when a page is removed from swap
cache: so there's a category of ex-swap pages that are easily
migratable, but were inadvertently excluded from compaction's async
migration in 4.16.
Link: http://lkml.kernel.org/r/alpine.LSU.2.11.1805302014001.12558@eggly.anvils
Fixes: 69d763fc6d3a ("mm: pin address_space before dereferencing it while isolating an LRU page")
Signed-off-by: Hugh Dickins <hughd(a)google.com>
Acked-by: Minchan Kim <minchan(a)kernel.org>
Acked-by: Mel Gorman <mgorman(a)techsingularity.net>
Reported-by: Ivan Kalvachev <ikalvachev(a)gmail.com>
Cc: "Huang, Ying" <ying.huang(a)intel.com>
Cc: Jan Kara <jack(a)suse.cz>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
---
mm/vmscan.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/vmscan.c b/mm/vmscan.c
index 9b697323a88c..9270a4370d54 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -1418,7 +1418,7 @@ int __isolate_lru_page(struct page *page, isolate_mode_t mode)
return ret;
mapping = page_mapping(page);
- migrate_dirty = mapping && mapping->a_ops->migratepage;
+ migrate_dirty = !mapping || mapping->a_ops->migratepage;
unlock_page(page);
if (!migrate_dirty)
return ret;
--
1.8.4.5
When panic happens while BAU is active there is a chance that
outstanding broadcasts tie up BAU resources enough to cause timeouts in
the UV ASIC. These timeouts are hardware errors that immediately bring
down the system, preventing kdump from completing.
Add uv_bau_crash_shutdown() to bring BAU to quiescence during panic before
continuing with the native crash shutdown. Assign uv_bau_crash_shutdown
to machine_ops during init.
Signed-off-by: Andrew Banman <abanman(a)hpe.com>
---
arch/x86/platform/uv/tlb_uv.c | 31 +++++++++++++++++++++++++++++++
1 file changed, 31 insertions(+)
diff --git a/arch/x86/platform/uv/tlb_uv.c b/arch/x86/platform/uv/tlb_uv.c
index b36caae..e7f9aea 100644
--- a/arch/x86/platform/uv/tlb_uv.c
+++ b/arch/x86/platform/uv/tlb_uv.c
@@ -22,6 +22,7 @@
#include <asm/tsc.h>
#include <asm/irq_vectors.h>
#include <asm/timer.h>
+#include <asm/reboot.h>
static struct bau_operations ops __ro_after_init;
@@ -2197,6 +2198,32 @@ static int __init init_per_cpu(int nuvhubs, int base_part_pnode)
.wait_completion = uv4_wait_completion,
};
+#ifdef CONFIG_KEXEC_CORE
+/*
+ * Bring BAU to quiesence by disabling future broadcasts and abandoning
+ * current broadcasts during panic.
+ */
+void uv_bau_crash_shutdown(struct pt_regs *regs)
+{
+ set_bau_off();
+ nobau_perm = 1;
+
+ for_each_possible_blade(uvhub) {
+ if (!uv_blade_nr_possible_cpus(uvhub))
+ continue;
+ int pnode = uv_blade_to_pnode(uvhub);
+ /* Set STATUS registers to idle to free source cpus */
+ write_gmmr(pnode, UVH_LB_BAU_SB_ACTIVATION_STATUS_0, 0x0);
+ write_gmmr(pnode, UVH_LB_BAU_SB_ACTIVATION_STATUS_1, 0x0);
+ write_gmmr(pnode, UVH_LB_BAU_SB_ACTIVATION_STATUS_2, 0x0);
+ /* Clear TIMEOUT and PENDING bits to free up BAU resources */
+ ops.write_g_sw_ack(pnode, ops.read_g_sw_ack(pnode) & 0xFFFF);
+ }
+
+ native_machine_crash_shutdown(regs);
+}
+#endif
+
/*
* Initialization of BAU-related structures
*/
@@ -2269,6 +2296,10 @@ static int __init uv_bau_init(void)
}
}
+#ifdef CONFIG_KEXEC_CORE
+ machine_ops.crash_shutdown = uv_bau_crash_shutdown;
+#endif
+
return 0;
err_bau_disable:
--
1.8.2.1
Hi Greg,
Please queue up this series of patches for 4.9 if you have no objections.
The first one is not a backport but a fix for a previous backport.
cheers
Mauricio Faria de Oliveira (4):
powerpc/rfi-flush: Differentiate enabled and patched flush types
powerpc/pseries: Fix clearing of security feature flags
powerpc: Move default security feature flags
powerpc/pseries: Restore default security feature flags on setup
Michael Ellerman (18):
powerpc/rfi-flush: Move out of HARDLOCKUP_DETECTOR #ifdef
powerpc/pseries: Support firmware disable of RFI flush
powerpc/powernv: Support firmware disable of RFI flush
powerpc/rfi-flush: Move the logic to avoid a redo into the debugfs
code
powerpc/rfi-flush: Make it possible to call setup_rfi_flush() again
powerpc/rfi-flush: Always enable fallback flush on pseries
powerpc/rfi-flush: Call setup_rfi_flush() after LPM migration
powerpc/pseries: Add new H_GET_CPU_CHARACTERISTICS flags
powerpc: Add security feature flags for Spectre/Meltdown
powerpc/pseries: Set or clear security feature flags
powerpc/powernv: Set or clear security feature flags
powerpc/64s: Move cpu_show_meltdown()
powerpc/64s: Enhance the information in cpu_show_meltdown()
powerpc/powernv: Use the security flags in pnv_setup_rfi_flush()
powerpc/pseries: Use the security flags in pseries_setup_rfi_flush()
powerpc/64s: Wire up cpu_show_spectre_v1()
powerpc/64s: Wire up cpu_show_spectre_v2()
powerpc/64s: Fix section mismatch warnings from setup_rfi_flush()
Nicholas Piggin (1):
powerpc/64s: Add support for a store forwarding barrier at kernel
entry/exit
arch/powerpc/include/asm/exception-64s.h | 29 ++++
arch/powerpc/include/asm/feature-fixups.h | 19 +++
arch/powerpc/include/asm/hvcall.h | 3 +
arch/powerpc/include/asm/security_features.h | 85 ++++++++++
arch/powerpc/include/asm/setup.h | 2 +-
arch/powerpc/kernel/Makefile | 2 +-
arch/powerpc/kernel/exceptions-64s.S | 16 +-
arch/powerpc/kernel/security.c | 237 +++++++++++++++++++++++++++
arch/powerpc/kernel/setup_64.c | 37 ++---
arch/powerpc/kernel/vmlinux.lds.S | 14 ++
arch/powerpc/lib/feature-fixups.c | 124 +++++++++++++-
arch/powerpc/platforms/powernv/setup.c | 92 ++++++++---
arch/powerpc/platforms/pseries/mobility.c | 3 +
arch/powerpc/platforms/pseries/pseries.h | 2 +
arch/powerpc/platforms/pseries/setup.c | 81 +++++++--
15 files changed, 679 insertions(+), 67 deletions(-)
create mode 100644 arch/powerpc/include/asm/security_features.h
create mode 100644 arch/powerpc/kernel/security.c
--
2.14.1
Hi Greg,
The following patches are needed in various stable releases to build
sparc/sparc64 images with gcc 7.3.0.
v4.4:
56962f8b250a Kbuild: change CC_OPTIMIZE_FOR_SIZE definition
v4.9 and earlier:
0fde7ad71ee3 sparc64: Fix build warnings with gcc 7.
v4.9:
009615ab7fd4 USB: serial: cp210x: use tcflag_t to fix incompatible pointer type
Thanks,
Guenter
The patch below does not apply to the 4.16-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From a9e8d27574f26700575473011cb607d4abdbda5f Mon Sep 17 00:00:00 2001
From: David Francis <David.Francis(a)amd.com>
Date: Thu, 31 May 2018 13:48:31 -0400
Subject: [PATCH] drm/amd/display: Make atomic-check validate underscan changes
When the underscan state was changed, atomic-check was triggering a
validation but passing the old underscan values. This change adds a
somewhat hacky check in dm_update_crtcs_state that will update the
stream if old and newunderscan values are different.
This was causing 4k on Fiji to allow underscan when it wasn't permitted.
Signed-off-by: David Francis <David.Francis(a)amd.com>
Reviewed-by: David Francis <David.Francis(a)amd.com>
Acked-by: Harry Wentland <harry.wentland(a)amd.com>
Cc: stable(a)vger.kernel.org
Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com>
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index ad1ad333012a..1a7e96ee6051 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -4555,8 +4555,8 @@ static int dm_update_crtcs_state(struct dc *dc,
for_each_oldnew_crtc_in_state(state, crtc, old_crtc_state, new_crtc_state, i) {
struct amdgpu_crtc *acrtc = NULL;
struct amdgpu_dm_connector *aconnector = NULL;
- struct drm_connector_state *new_con_state = NULL;
- struct dm_connector_state *dm_conn_state = NULL;
+ struct drm_connector_state *drm_new_conn_state = NULL, *drm_old_conn_state = NULL;
+ struct dm_connector_state *dm_new_conn_state = NULL, *dm_old_conn_state = NULL;
struct drm_plane_state *new_plane_state = NULL;
new_stream = NULL;
@@ -4577,19 +4577,23 @@ static int dm_update_crtcs_state(struct dc *dc,
/* TODO This hack should go away */
if (aconnector && enable) {
// Make sure fake sink is created in plug-in scenario
- new_con_state = drm_atomic_get_connector_state(state,
+ drm_new_conn_state = drm_atomic_get_new_connector_state(state,
&aconnector->base);
+ drm_old_conn_state = drm_atomic_get_old_connector_state(state,
+ &aconnector->base);
- if (IS_ERR(new_con_state)) {
- ret = PTR_ERR_OR_ZERO(new_con_state);
+
+ if (IS_ERR(drm_new_conn_state)) {
+ ret = PTR_ERR_OR_ZERO(drm_new_conn_state);
break;
}
- dm_conn_state = to_dm_connector_state(new_con_state);
+ dm_new_conn_state = to_dm_connector_state(drm_new_conn_state);
+ dm_old_conn_state = to_dm_connector_state(drm_old_conn_state);
new_stream = create_stream_for_sink(aconnector,
&new_crtc_state->mode,
- dm_conn_state);
+ dm_new_conn_state);
/*
* we can have no stream on ACTION_SET if a display
@@ -4708,6 +4712,11 @@ static int dm_update_crtcs_state(struct dc *dc,
*/
BUG_ON(dm_new_crtc_state->stream == NULL);
+ /* Scaling or underscan settings */
+ if (is_scaling_state_different(dm_old_conn_state, dm_new_conn_state))
+ update_stream_scaling_settings(
+ &new_crtc_state->mode, dm_new_conn_state, dm_new_crtc_state->stream);
+
/* Color managment settings */
if (dm_new_crtc_state->base.color_mgmt_changed) {
ret = amdgpu_dm_set_regamma_lut(dm_new_crtc_state);
The patch below does not apply to the 4.16-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From bc13f2f88eae63af943ab967cb14bb602f8f2eeb Mon Sep 17 00:00:00 2001
From: "Leo (Sunpeng) Li" <sunpeng.li(a)amd.com>
Date: Thu, 31 May 2018 10:23:37 -0400
Subject: [PATCH] drm/amd/display: Update color props when modeset is required
This fixes issues where color management properties don't persist
over DPMS on/off, or when the CRTC is moved across connectors.
Signed-off-by: Leo (Sunpeng) Li <sunpeng.li(a)amd.com>
Reviewed-by: Harry Wentland <Harry.Wentland(a)amd.com>
Cc: stable(a)vger.kernel.org
Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com>
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 1a7e96ee6051..27579443cdc5 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -4717,8 +4717,12 @@ static int dm_update_crtcs_state(struct dc *dc,
update_stream_scaling_settings(
&new_crtc_state->mode, dm_new_conn_state, dm_new_crtc_state->stream);
- /* Color managment settings */
- if (dm_new_crtc_state->base.color_mgmt_changed) {
+ /*
+ * Color management settings. We also update color properties
+ * when a modeset is needed, to ensure it gets reprogrammed.
+ */
+ if (dm_new_crtc_state->base.color_mgmt_changed ||
+ drm_atomic_crtc_needs_modeset(new_crtc_state)) {
ret = amdgpu_dm_set_regamma_lut(dm_new_crtc_state);
if (ret)
goto fail;
The patch below does not apply to the 4.4-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From a840c93ca7582bb6c88df2345a33f979b7a67874 Mon Sep 17 00:00:00 2001
From: Parav Pandit <parav(a)mellanox.com>
Date: Sun, 27 May 2018 14:49:16 +0300
Subject: [PATCH] IB/core: Fix error code for invalid GID entry
When a GID entry is invalid EAGAIN is returned. This is an incorrect error
code, there is nothing that will make this GID entry valid again in
bounded time.
Some user space tools fail incorrectly if EAGAIN is returned here, and
this represents a small ABI change from earlier kernels.
The first patch in the Fixes list makes entries that were valid before
to become invalid, allowing this code to trigger, while the second patch
in the Fixes list introduced the wrong EAGAIN.
Therefore revert the return result to EINVAL which matches the historical
expectations of the ibv_query_gid_type() API of the libibverbs user space
library.
Cc: <stable(a)vger.kernel.org>
Fixes: 598ff6bae689 ("IB/core: Refactor GID modify code for RoCE")
Fixes: 03db3a2d81e6 ("IB/core: Add RoCE GID table management")
Reviewed-by: Daniel Jurgens <danielj(a)mellanox.com>
Signed-off-by: Parav Pandit <parav(a)mellanox.com>
Signed-off-by: Leon Romanovsky <leonro(a)mellanox.com>
Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com>
diff --git a/drivers/infiniband/core/cache.c b/drivers/infiniband/core/cache.c
index fb2d347f760f..ecc55e98ddd3 100644
--- a/drivers/infiniband/core/cache.c
+++ b/drivers/infiniband/core/cache.c
@@ -502,7 +502,7 @@ static int __ib_cache_gid_get(struct ib_device *ib_dev, u8 port, int index,
return -EINVAL;
if (table->data_vec[index].props & GID_TABLE_ENTRY_INVALID)
- return -EAGAIN;
+ return -EINVAL;
memcpy(gid, &table->data_vec[index].gid, sizeof(*gid));
if (attr) {
[ Not relevant upstream, therefore no upstream commit. ]
To fix, unmap the page as soon as possible.
When swiotlb is in use, calling dma_unmap_page means that
the original page mapped with dma_map_page must still be valid,
as swiotlb will copy data from its internal cache back to the
originally requested DMA location.
When GRO is enabled, before this patch all references to the
original frag may be put and the page freed before dma_unmap_page
in mlx4_en_free_frag is called.
It is possible there is a path where the use-after-free occurs
even with GRO disabled, but this has not been observed so far.
The bug can be trivially detected by doing the following:
* Compile the kernel with DEBUG_PAGEALLOC
* Run the kernel as a Xen Dom0
* Leave GRO enabled on the interface
* Run a 10 second or more test with iperf over the interface.
This bug was likely introduced in
commit 4cce66cdd14a ("mlx4_en: map entire pages to increase throughput"),
first part of u3.6.
It was incidentally fixed in
commit 34db548bfb95 ("mlx4: add page recycling in receive path"),
first part of v4.12.
This version applies to the v4.9 series.
Signed-off-by: Sarah Newman <srn(a)prgmr.com>
Tested-by: Sarah Newman <srn(a)prgmr.com>
---
drivers/net/ethernet/mellanox/mlx4/en_rx.c | 32 +++++++++++++++++++-----------
1 file changed, 20 insertions(+), 12 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_rx.c b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
index 844f5ad..abe2b43 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_rx.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
@@ -142,16 +142,17 @@ static void mlx4_en_free_frag(struct mlx4_en_priv *priv,
struct mlx4_en_rx_alloc *frags,
int i)
{
- const struct mlx4_en_frag_info *frag_info = &priv->frag_info[i];
- u32 next_frag_end = frags[i].page_offset + 2 * frag_info->frag_stride;
-
-
- if (next_frag_end > frags[i].page_size)
- dma_unmap_page(priv->ddev, frags[i].dma, frags[i].page_size,
- frag_info->dma_dir);
+ if (frags[i].page) {
+ const struct mlx4_en_frag_info *frag_info = &priv->frag_info[i];
+ u32 next_frag_end = frags[i].page_offset +
+ 2 * frag_info->frag_stride;
- if (frags[i].page)
+ if (next_frag_end > frags[i].page_size) {
+ dma_unmap_page(priv->ddev, frags[i].dma,
+ frags[i].page_size, frag_info->dma_dir);
+ }
put_page(frags[i].page);
+ }
}
static int mlx4_en_init_allocator(struct mlx4_en_priv *priv,
@@ -586,21 +587,28 @@ static int mlx4_en_complete_rx_desc(struct mlx4_en_priv *priv,
int length)
{
struct skb_frag_struct *skb_frags_rx = skb_shinfo(skb)->frags;
- struct mlx4_en_frag_info *frag_info;
int nr;
dma_addr_t dma;
/* Collect used fragments while replacing them in the HW descriptors */
for (nr = 0; nr < priv->num_frags; nr++) {
- frag_info = &priv->frag_info[nr];
+ struct mlx4_en_frag_info *frag_info = &priv->frag_info[nr];
+ u32 next_frag_end = frags[nr].page_offset +
+ 2 * frag_info->frag_stride;
+
if (length <= frag_info->frag_prefix_size)
break;
if (unlikely(!frags[nr].page))
goto fail;
dma = be64_to_cpu(rx_desc->data[nr].addr);
- dma_sync_single_for_cpu(priv->ddev, dma, frag_info->frag_size,
- DMA_FROM_DEVICE);
+ if (next_frag_end > frags[nr].page_size)
+ dma_unmap_page(priv->ddev, frags[nr].dma,
+ frags[nr].page_size, frag_info->dma_dir);
+ else
+ dma_sync_single_for_cpu(priv->ddev, dma,
+ frag_info->frag_size,
+ DMA_FROM_DEVICE);
/* Save page reference in skb */
__skb_frag_set_page(&skb_frags_rx[nr], frags[nr].page);
--
1.9.1
Patch 0aa3fdb8b3a6 ("scsi: sd_zbc: Fix potential memory leak") was added in
4.16 and 4.15 stable but did not make it to long term stable 4.14 (as far as I
can tell).
Patch ccce20fc7968 ("scsi: sd_zbc: Avoid that resetting a zone fails
sporadically") is included in 4.16 but does not apply to 4.15 stable nor to
4.14 long term stable and requires extensive modifications.
This small series provides a backport of both patches against 4.14. Please
consider these patches for inclusion in this long term stable kernel.
Bart Van Assche (1):
scsi: sd_zbc: Avoid that resetting a zone fails sporadically
Damien Le Moal (1):
scsi: sd_zbc: Fix potential memory leak
drivers/scsi/sd_zbc.c | 128 +++++++++++++++++++++++++-----------------
1 file changed, 76 insertions(+), 52 deletions(-)
--
2.17.0
From: Yoshihiro Shimoda <yoshihiro.shimoda.uh(a)renesas.com>
commit d9f5efade2cfd729138a7cafb46d01044da40f5e upstream
This patch fixes an issue that list_for_each_entry() in
usb_dmac_chan_terminate_all() is possible to cause endless loop because
this will move own desc to the desc_freed. So, this driver should use
list_for_each_entry_safe() instead of list_for_each_entry().
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh(a)renesas.com>
Signed-off-by: Vinod Koul <vinod.koul(a)intel.com>
[biju: cherry-pick to 4.4]
Signed-off-by: Biju Das <biju.das(a)bp.renesas.com>
---
Hello Greg,
I have observed a CPU lock condition with USB DMAC driver on koelsch platform.
This patch fixes the issue on 4.4 stable. It is reproducible with ethernet(RNDIS/ECM)
gadget configuration.
regards,
Biju
drivers/dma/sh/usb-dmac.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/dma/sh/usb-dmac.c b/drivers/dma/sh/usb-dmac.c
index 56410ea..6682b3e 100644
--- a/drivers/dma/sh/usb-dmac.c
+++ b/drivers/dma/sh/usb-dmac.c
@@ -448,7 +448,7 @@ usb_dmac_prep_slave_sg(struct dma_chan *chan, struct scatterlist *sgl,
static int usb_dmac_chan_terminate_all(struct dma_chan *chan)
{
struct usb_dmac_chan *uchan = to_usb_dmac_chan(chan);
- struct usb_dmac_desc *desc;
+ struct usb_dmac_desc *desc, *_desc;
unsigned long flags;
LIST_HEAD(head);
LIST_HEAD(list);
@@ -459,7 +459,7 @@ static int usb_dmac_chan_terminate_all(struct dma_chan *chan)
if (uchan->desc)
uchan->desc = NULL;
list_splice_init(&uchan->desc_got, &list);
- list_for_each_entry(desc, &list, node)
+ list_for_each_entry_safe(desc, _desc, &list, node)
list_move_tail(&desc->node, &uchan->desc_freed);
spin_unlock_irqrestore(&uchan->vc.lock, flags);
vchan_dma_desc_free_list(&uchan->vc, &head);
--
2.7.4
Hello Greg,
Wolfram recommends the backporting of this series in order to
improve the situation with a race condition.
Do you think you can take this series for 4.4 stable?
This series applies on 4.4.133, and depends on series:
"Fix R-Car I2C data byte sent twice issue"
Thanks,
Fab
Wolfram Sang (3):
i2c: rcar: don't issue stop when HW does it automatically
i2c: rcar: check master irqs before slave irqs
i2c: rcar: revoke START request early
drivers/i2c/busses/i2c-rcar.c | 36 ++++++++++++------------------------
1 file changed, 12 insertions(+), 24 deletions(-)
--
2.7.4
Hello Greg,
this series fixes an issue with the I2C driver of the Renesas R-Car and
RZ/G1 family of chips. The issue is clearly visible with the CIP kernel
(4.4) running on a iwg20d board from iWave due to the way the bq32000
driver/device is interacting with the I2C driver/controller.
In the stable kernel (4.4) there is no support for the iwg20d, I tried
to replicate the same problem on a Koelsch board with no success, but
the problem is there.
Do you think this series is suitable for (4.4) stable considering I
can't reproduce the problem on the Koelsch board?
This patches apply on top of 4.4.133.
Thanks,
Fab
Wolfram Sang (6):
i2c: rcar: make sure clocks are on when doing clock calculation
i2c: rcar: rework hw init
i2c: rcar: remove unused IOERROR state
i2c: rcar: remove spinlock
i2c: rcar: refactor setup of a msg
i2c: rcar: init new messages in irq
drivers/i2c/busses/i2c-rcar.c | 166 ++++++++++++++++++------------------------
1 file changed, 72 insertions(+), 94 deletions(-)
--
2.7.4
Above commit is a wrong backport, as it is based on a missing
prerequisite patch. Correct that by reverting said commit, include the
missing patch, and do the backport correctly.
Juergen Gross (3):
x86/amd: revert commit 944e0fc51a89c9827b98813d65dc083274777c7f
xen: set cpu capabilities from xen_start_kernel()
x86/amd: don't set X86_BUG_SYSRET_SS_ATTRS when running under Xen
arch/x86/xen/enlighten.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
--
2.13.6
Hi Greg,
the following are some more patches for stable releases.
I collected the following clang patches from chromeos-4.14. They are not
really needed to build x86_64:defconfig in v4.14.y with clang (5.0), but
they do fix a couple of build warnings if the respective drivers are enabled.
I'll leave it up to you if you want to apply them or not. I did make sure
that defconfig and allmodconfig still build using gcc with the patches
applied.
df16aaac26e9 kbuild: clang: remove crufty HOSTCFLAGS
cad9946c2a43 drm/i915: Always sanity check engine state upon idling
531beb067c61 dma-buf: remove redundant initialization of sg_table
42b5122e828a drm/amd/powerplay: Fix enum mismatch
fb239c1209bb rtlwifi: rtl8192cu: Remove variable self-assignment in rf.c
271ef65b5882 ASoC: Intel: sst: remove redundant variable dma_dev_name
d3b56c566d4b platform/chrome: cros_ec_lpc: remove redundant pointer request
0a5f41767444 kbuild: clang: disable unused variable warnings
The following patch is needed in v4.4.y to be able to build
arm:footbridge_defconfig with gcc 7.3.0.
c9bd28233b6d irda: fix overly long udelay()
Thanks,
Guenter
From: Hugh Dickins <hughd(a)google.com>
Subject: mm/huge_memory.c: __split_huge_page() use atomic ClearPageDirty()
Swapping load on huge=always tmpfs (with khugepaged tuned up to be very
eager, but I'm not sure that is relevant) soon hung uninterruptibly,
waiting for page lock in shmem_getpage_gfp()'s find_lock_entry(), most
often when "cp -a" was trying to write to a smallish file. Debug showed
that the page in question was not locked, and page->mapping NULL by now,
but page->index consistent with having been in a huge page before.
Reproduced in minutes on a 4.15 kernel, even with 4.17's 605ca5ede764
("mm/huge_memory.c: reorder operations in __split_huge_page_tail()") added
in; but took hours to reproduce on a 4.17 kernel (no idea why).
The culprit proved to be the __ClearPageDirty() on tails beyond i_size in
__split_huge_page(): the non-atomic __bitoperation may have been safe when
4.8's baa355fd3314 ("thp: file pages support for split_huge_page()")
introduced it, but liable to erase PageWaiters after 4.10's 62906027091f
("mm: add PageWaiters indicating tasks are waiting for a page bit").
Link: http://lkml.kernel.org/r/alpine.LSU.2.11.1805291841070.3197@eggly.anvils
Fixes: 62906027091f ("mm: add PageWaiters indicating tasks are waiting for a page bit")
Signed-off-by: Hugh Dickins <hughd(a)google.com>
Acked-by: Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com>
Cc: Konstantin Khlebnikov <khlebnikov(a)yandex-team.ru>
Cc: Nicholas Piggin <npiggin(a)gmail.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
mm/huge_memory.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -puN mm/huge_memory.c~mm-huge_memoryc-__split_huge_page-use-atomic-clearpagedirty mm/huge_memory.c
--- a/mm/huge_memory.c~mm-huge_memoryc-__split_huge_page-use-atomic-clearpagedirty
+++ a/mm/huge_memory.c
@@ -2431,7 +2431,7 @@ static void __split_huge_page(struct pag
__split_huge_page_tail(head, i, lruvec, list);
/* Some pages can be beyond i_size: drop them from page cache */
if (head[i].index >= end) {
- __ClearPageDirty(head + i);
+ ClearPageDirty(head + i);
__delete_from_page_cache(head + i, NULL);
if (IS_ENABLED(CONFIG_SHMEM) && PageSwapBacked(head))
shmem_uncharge(head->mapping->host, 1);
_