* [PATCH 5.4 01/57] dma-buf: Fix SET_NAME ioctl uapi
2020-05-04 17:57 [PATCH 5.4 00/57] 5.4.39-rc1 review Greg Kroah-Hartman
@ 2020-05-04 17:57 ` Greg Kroah-Hartman
2020-05-04 17:57 ` [PATCH 5.4 02/57] drm/edid: Fix off-by-one in DispID DTD pixel clock Greg Kroah-Hartman
` (59 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: Greg Kroah-Hartman @ 2020-05-04 17:57 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Sumit Semwal, Chenbo Feng,
Greg Hackmann, Daniel Vetter, linux-media, linaro-mm-sig,
minchan, surenb, jenhaochen, Martin Liu, Daniel Vetter
From: Daniel Vetter <daniel.vetter@intel.com>
commit a5bff92eaac45bdf6221badf9505c26792fdf99e upstream.
The uapi is the same on 32 and 64 bit, but the number isn't. Everyone
who botched this please re-read:
https://www.kernel.org/doc/html/v5.4-preprc-cpu/ioctl/botching-up-ioctls.html
Also, the type argument for the ioctl macros is for the type the void
__user *arg pointer points at, which in this case would be the
variable-sized char[] of a 0 terminated string. So this was botched in
more than just the usual ways.
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Cc: Chenbo Feng <fengc@google.com>
Cc: Greg Hackmann <ghackmann@google.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: linux-media@vger.kernel.org
Cc: linaro-mm-sig@lists.linaro.org
Cc: minchan@kernel.org
Cc: surenb@google.com
Cc: jenhaochen@google.com
Cc: Martin Liu <liumartin@google.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Tested-by: Martin Liu <liumartin@google.com>
Reviewed-by: Martin Liu <liumartin@google.com>
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
[sumits: updated some checkpatch fixes, corrected author email]
Link: https://patchwork.freedesktop.org/patch/msgid/20200407133002.3486387-1-daniel.vetter@ffwll.ch
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/dma-buf/dma-buf.c | 3 ++-
include/uapi/linux/dma-buf.h | 6 ++++++
2 files changed, 8 insertions(+), 1 deletion(-)
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -388,7 +388,8 @@ static long dma_buf_ioctl(struct file *f
return ret;
- case DMA_BUF_SET_NAME:
+ case DMA_BUF_SET_NAME_A:
+ case DMA_BUF_SET_NAME_B:
return dma_buf_set_name(dmabuf, (const char __user *)arg);
default:
--- a/include/uapi/linux/dma-buf.h
+++ b/include/uapi/linux/dma-buf.h
@@ -39,6 +39,12 @@ struct dma_buf_sync {
#define DMA_BUF_BASE 'b'
#define DMA_BUF_IOCTL_SYNC _IOW(DMA_BUF_BASE, 0, struct dma_buf_sync)
+
+/* 32/64bitness of this uapi was botched in android, there's no difference
+ * between them in actual uapi, they're just different numbers.
+ */
#define DMA_BUF_SET_NAME _IOW(DMA_BUF_BASE, 1, const char *)
+#define DMA_BUF_SET_NAME_A _IOW(DMA_BUF_BASE, 1, u32)
+#define DMA_BUF_SET_NAME_B _IOW(DMA_BUF_BASE, 1, u64)
#endif
^ permalink raw reply [flat|nested] 62+ messages in thread* [PATCH 5.4 02/57] drm/edid: Fix off-by-one in DispID DTD pixel clock
2020-05-04 17:57 [PATCH 5.4 00/57] 5.4.39-rc1 review Greg Kroah-Hartman
2020-05-04 17:57 ` [PATCH 5.4 01/57] dma-buf: Fix SET_NAME ioctl uapi Greg Kroah-Hartman
@ 2020-05-04 17:57 ` Greg Kroah-Hartman
2020-05-04 17:57 ` [PATCH 5.4 03/57] drm/amd/display: Fix green screen issue after suspend Greg Kroah-Hartman
` (58 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: Greg Kroah-Hartman @ 2020-05-04 17:57 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Ville Syrjälä, Manasi Navare
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
commit 6292b8efe32e6be408af364132f09572aed14382 upstream.
The DispID DTD pixel clock is documented as:
"00 00 00 h → FF FF FF h | Pixel clock ÷ 10,000 0.01 → 167,772.16 Mega Pixels per Sec"
Which seems to imply that we to add one to the raw value.
Reality seems to agree as there are tiled displays in the wild
which currently show a 10kHz difference in the pixel clock
between the tiles (one tile gets its mode from the base EDID,
the other from the DispID block).
Cc: stable@vger.kernel.org
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200423151743.18767-1-ville.syrjala@linux.intel.com
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/drm_edid.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4743,7 +4743,7 @@ static struct drm_display_mode *drm_mode
struct drm_display_mode *mode;
unsigned pixel_clock = (timings->pixel_clock[0] |
(timings->pixel_clock[1] << 8) |
- (timings->pixel_clock[2] << 16));
+ (timings->pixel_clock[2] << 16)) + 1;
unsigned hactive = (timings->hactive[0] | timings->hactive[1] << 8) + 1;
unsigned hblank = (timings->hblank[0] | timings->hblank[1] << 8) + 1;
unsigned hsync = (timings->hsync[0] | (timings->hsync[1] & 0x7f) << 8) + 1;
^ permalink raw reply [flat|nested] 62+ messages in thread* [PATCH 5.4 03/57] drm/amd/display: Fix green screen issue after suspend
2020-05-04 17:57 [PATCH 5.4 00/57] 5.4.39-rc1 review Greg Kroah-Hartman
2020-05-04 17:57 ` [PATCH 5.4 01/57] dma-buf: Fix SET_NAME ioctl uapi Greg Kroah-Hartman
2020-05-04 17:57 ` [PATCH 5.4 02/57] drm/edid: Fix off-by-one in DispID DTD pixel clock Greg Kroah-Hartman
@ 2020-05-04 17:57 ` Greg Kroah-Hartman
2020-05-04 17:57 ` [PATCH 5.4 04/57] drm/qxl: qxl_release leak in qxl_draw_dirty_fb() Greg Kroah-Hartman
` (57 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: Greg Kroah-Hartman @ 2020-05-04 17:57 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Nicholas Kazlauskas,
Rodrigo Siqueira, Nicholas Kazlauskas, Alex Deucher
From: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
commit 87b7ebc2e16c14d32a912f18206a4d6cc9abc3e8 upstream.
[why]
We have seen a green screen after resume from suspend in a Raven system
connected with two displays (HDMI and DP) on X based system. We noticed
that this issue is related to bad DCC metadata from user space which may
generate hangs and consequently an underflow on HUBP. After taking a
deep look at the code path we realized that after resume we try to
restore the commit with the DCC enabled framebuffer but the framebuffer
is no longer valid.
[how]
This problem was only reported on Raven based system and after suspend,
for this reason, this commit adds a new parameter on
fill_plane_dcc_attributes() to give the option of disabling DCC
programmatically. In summary, for disabling DCC we first verify if is a
Raven system and if it is in suspend; if both conditions are true we
disable DCC temporarily, otherwise, it is enabled.
Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1099
Co-developed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Signed-off-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Reviewed-by: Nicholas Kazlauskas <Nicholas.Kazlauskas@amd.com>
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 38 ++++++++++++++++------
1 file changed, 29 insertions(+), 9 deletions(-)
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -2698,7 +2698,8 @@ fill_plane_dcc_attributes(struct amdgpu_
const union dc_tiling_info *tiling_info,
const uint64_t info,
struct dc_plane_dcc_param *dcc,
- struct dc_plane_address *address)
+ struct dc_plane_address *address,
+ bool force_disable_dcc)
{
struct dc *dc = adev->dm.dc;
struct dc_dcc_surface_param input;
@@ -2710,6 +2711,9 @@ fill_plane_dcc_attributes(struct amdgpu_
memset(&input, 0, sizeof(input));
memset(&output, 0, sizeof(output));
+ if (force_disable_dcc)
+ return 0;
+
if (!offset)
return 0;
@@ -2759,7 +2763,8 @@ fill_plane_buffer_attributes(struct amdg
union dc_tiling_info *tiling_info,
struct plane_size *plane_size,
struct dc_plane_dcc_param *dcc,
- struct dc_plane_address *address)
+ struct dc_plane_address *address,
+ bool force_disable_dcc)
{
const struct drm_framebuffer *fb = &afb->base;
int ret;
@@ -2869,7 +2874,8 @@ fill_plane_buffer_attributes(struct amdg
ret = fill_plane_dcc_attributes(adev, afb, format, rotation,
plane_size, tiling_info,
- tiling_flags, dcc, address);
+ tiling_flags, dcc, address,
+ force_disable_dcc);
if (ret)
return ret;
}
@@ -2961,7 +2967,8 @@ fill_dc_plane_info_and_addr(struct amdgp
const struct drm_plane_state *plane_state,
const uint64_t tiling_flags,
struct dc_plane_info *plane_info,
- struct dc_plane_address *address)
+ struct dc_plane_address *address,
+ bool force_disable_dcc)
{
const struct drm_framebuffer *fb = plane_state->fb;
const struct amdgpu_framebuffer *afb =
@@ -3040,7 +3047,8 @@ fill_dc_plane_info_and_addr(struct amdgp
plane_info->rotation, tiling_flags,
&plane_info->tiling_info,
&plane_info->plane_size,
- &plane_info->dcc, address);
+ &plane_info->dcc, address,
+ force_disable_dcc);
if (ret)
return ret;
@@ -3063,6 +3071,7 @@ static int fill_dc_plane_attributes(stru
struct dc_plane_info plane_info;
uint64_t tiling_flags;
int ret;
+ bool force_disable_dcc = false;
ret = fill_dc_scaling_info(plane_state, &scaling_info);
if (ret)
@@ -3077,9 +3086,11 @@ static int fill_dc_plane_attributes(stru
if (ret)
return ret;
+ force_disable_dcc = adev->asic_type == CHIP_RAVEN && adev->in_suspend;
ret = fill_dc_plane_info_and_addr(adev, plane_state, tiling_flags,
&plane_info,
- &dc_plane_state->address);
+ &dc_plane_state->address,
+ force_disable_dcc);
if (ret)
return ret;
@@ -4481,6 +4492,7 @@ static int dm_plane_helper_prepare_fb(st
uint64_t tiling_flags;
uint32_t domain;
int r;
+ bool force_disable_dcc = false;
dm_plane_state_old = to_dm_plane_state(plane->state);
dm_plane_state_new = to_dm_plane_state(new_state);
@@ -4539,11 +4551,13 @@ static int dm_plane_helper_prepare_fb(st
dm_plane_state_old->dc_state != dm_plane_state_new->dc_state) {
struct dc_plane_state *plane_state = dm_plane_state_new->dc_state;
+ force_disable_dcc = adev->asic_type == CHIP_RAVEN && adev->in_suspend;
fill_plane_buffer_attributes(
adev, afb, plane_state->format, plane_state->rotation,
tiling_flags, &plane_state->tiling_info,
&plane_state->plane_size, &plane_state->dcc,
- &plane_state->address);
+ &plane_state->address,
+ force_disable_dcc);
}
return 0;
@@ -5767,7 +5781,12 @@ static void amdgpu_dm_commit_planes(stru
fill_dc_plane_info_and_addr(
dm->adev, new_plane_state, tiling_flags,
&bundle->plane_infos[planes_count],
- &bundle->flip_addrs[planes_count].address);
+ &bundle->flip_addrs[planes_count].address,
+ false);
+
+ DRM_DEBUG_DRIVER("plane: id=%d dcc_en=%d\n",
+ new_plane_state->plane->index,
+ bundle->plane_infos[planes_count].dcc.enable);
bundle->surface_updates[planes_count].plane_info =
&bundle->plane_infos[planes_count];
@@ -7138,7 +7157,8 @@ dm_determine_update_type_for_commit(stru
ret = fill_dc_plane_info_and_addr(
dm->adev, new_plane_state, tiling_flags,
&plane_info,
- &flip_addr.address);
+ &flip_addr.address,
+ false);
if (ret)
goto cleanup;
^ permalink raw reply [flat|nested] 62+ messages in thread* [PATCH 5.4 04/57] drm/qxl: qxl_release leak in qxl_draw_dirty_fb()
2020-05-04 17:57 [PATCH 5.4 00/57] 5.4.39-rc1 review Greg Kroah-Hartman
` (2 preceding siblings ...)
2020-05-04 17:57 ` [PATCH 5.4 03/57] drm/amd/display: Fix green screen issue after suspend Greg Kroah-Hartman
@ 2020-05-04 17:57 ` Greg Kroah-Hartman
2020-05-04 17:57 ` [PATCH 5.4 05/57] drm/qxl: qxl_release leak in qxl_hw_surface_alloc() Greg Kroah-Hartman
` (56 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: Greg Kroah-Hartman @ 2020-05-04 17:57 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Vasily Averin, Gerd Hoffmann
From: Vasily Averin <vvs@virtuozzo.com>
commit 85e9b88af1e6164f19ec71381efd5e2bcfc17620 upstream.
ret should be changed to release allocated struct qxl_release
Cc: stable@vger.kernel.org
Fixes: 8002db6336dd ("qxl: convert qxl driver to proper use for reservations")
Signed-off-by: Vasily Averin <vvs@virtuozzo.com>
Link: http://patchwork.freedesktop.org/patch/msgid/22cfd55f-07c8-95d0-a2f7-191b7153c3d4@virtuozzo.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/qxl/qxl_draw.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
--- a/drivers/gpu/drm/qxl/qxl_draw.c
+++ b/drivers/gpu/drm/qxl/qxl_draw.c
@@ -209,9 +209,10 @@ void qxl_draw_dirty_fb(struct qxl_device
goto out_release_backoff;
rects = drawable_set_clipping(qdev, num_clips, clips_bo);
- if (!rects)
+ if (!rects) {
+ ret = -EINVAL;
goto out_release_backoff;
-
+ }
drawable = (struct qxl_drawable *)qxl_release_map(qdev, release);
drawable->clip.type = SPICE_CLIP_TYPE_RECTS;
^ permalink raw reply [flat|nested] 62+ messages in thread* [PATCH 5.4 05/57] drm/qxl: qxl_release leak in qxl_hw_surface_alloc()
2020-05-04 17:57 [PATCH 5.4 00/57] 5.4.39-rc1 review Greg Kroah-Hartman
` (3 preceding siblings ...)
2020-05-04 17:57 ` [PATCH 5.4 04/57] drm/qxl: qxl_release leak in qxl_draw_dirty_fb() Greg Kroah-Hartman
@ 2020-05-04 17:57 ` Greg Kroah-Hartman
2020-05-04 17:57 ` [PATCH 5.4 06/57] drm/qxl: qxl_release use after free Greg Kroah-Hartman
` (55 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: Greg Kroah-Hartman @ 2020-05-04 17:57 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Vasily Averin, Gerd Hoffmann
From: Vasily Averin <vvs@virtuozzo.com>
commit a65aa9c3676ffccb21361d52fcfedd5b5ff387d7 upstream.
Cc: stable@vger.kernel.org
Fixes: 8002db6336dd ("qxl: convert qxl driver to proper use for reservations")
Signed-off-by: Vasily Averin <vvs@virtuozzo.com>
Link: http://patchwork.freedesktop.org/patch/msgid/2e5a13ae-9ab2-5401-aa4d-03d5f5593423@virtuozzo.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/qxl/qxl_cmd.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
--- a/drivers/gpu/drm/qxl/qxl_cmd.c
+++ b/drivers/gpu/drm/qxl/qxl_cmd.c
@@ -480,9 +480,10 @@ int qxl_hw_surface_alloc(struct qxl_devi
return ret;
ret = qxl_release_reserve_list(release, true);
- if (ret)
+ if (ret) {
+ qxl_release_free(qdev, release);
return ret;
-
+ }
cmd = (struct qxl_surface_cmd *)qxl_release_map(qdev, release);
cmd->type = QXL_SURFACE_CMD_CREATE;
cmd->flags = QXL_SURF_FLAG_KEEP_DATA;
^ permalink raw reply [flat|nested] 62+ messages in thread* [PATCH 5.4 06/57] drm/qxl: qxl_release use after free
2020-05-04 17:57 [PATCH 5.4 00/57] 5.4.39-rc1 review Greg Kroah-Hartman
` (4 preceding siblings ...)
2020-05-04 17:57 ` [PATCH 5.4 05/57] drm/qxl: qxl_release leak in qxl_hw_surface_alloc() Greg Kroah-Hartman
@ 2020-05-04 17:57 ` Greg Kroah-Hartman
2020-05-04 17:57 ` [PATCH 5.4 07/57] NFSv4.1: fix handling of backchannel binding in BIND_CONN_TO_SESSION Greg Kroah-Hartman
` (54 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: Greg Kroah-Hartman @ 2020-05-04 17:57 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Vasily Averin, Gerd Hoffmann
From: Vasily Averin <vvs@virtuozzo.com>
commit 933db73351d359f74b14f4af095808260aff11f9 upstream.
qxl_release should not be accesses after qxl_push_*_ring_release() calls:
userspace driver can process submitted command quickly, move qxl_release
into release_ring, generate interrupt and trigger garbage collector.
It can lead to crashes in qxl driver or trigger memory corruption
in some kmalloc-192 slab object
Gerd Hoffmann proposes to swap the qxl_release_fence_buffer_objects() +
qxl_push_{cursor,command}_ring_release() calls to close that race window.
cc: stable@vger.kernel.org
Fixes: f64122c1f6ad ("drm: add new QXL driver. (v1.4)")
Signed-off-by: Vasily Averin <vvs@virtuozzo.com>
Link: http://patchwork.freedesktop.org/patch/msgid/fa17b338-66ae-f299-68fe-8d32419d9071@virtuozzo.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/qxl/qxl_cmd.c | 5 ++---
drivers/gpu/drm/qxl/qxl_display.c | 6 +++---
drivers/gpu/drm/qxl/qxl_draw.c | 2 +-
drivers/gpu/drm/qxl/qxl_ioctl.c | 5 +----
4 files changed, 7 insertions(+), 11 deletions(-)
--- a/drivers/gpu/drm/qxl/qxl_cmd.c
+++ b/drivers/gpu/drm/qxl/qxl_cmd.c
@@ -500,8 +500,8 @@ int qxl_hw_surface_alloc(struct qxl_devi
/* no need to add a release to the fence for this surface bo,
since it is only released when we ask to destroy the surface
and it would never signal otherwise */
- qxl_push_command_ring_release(qdev, release, QXL_CMD_SURFACE, false);
qxl_release_fence_buffer_objects(release);
+ qxl_push_command_ring_release(qdev, release, QXL_CMD_SURFACE, false);
surf->hw_surf_alloc = true;
spin_lock(&qdev->surf_id_idr_lock);
@@ -543,9 +543,8 @@ int qxl_hw_surface_dealloc(struct qxl_de
cmd->surface_id = id;
qxl_release_unmap(qdev, release, &cmd->release_info);
- qxl_push_command_ring_release(qdev, release, QXL_CMD_SURFACE, false);
-
qxl_release_fence_buffer_objects(release);
+ qxl_push_command_ring_release(qdev, release, QXL_CMD_SURFACE, false);
return 0;
}
--- a/drivers/gpu/drm/qxl/qxl_display.c
+++ b/drivers/gpu/drm/qxl/qxl_display.c
@@ -523,8 +523,8 @@ static int qxl_primary_apply_cursor(stru
cmd->u.set.visible = 1;
qxl_release_unmap(qdev, release, &cmd->release_info);
- qxl_push_cursor_ring_release(qdev, release, QXL_CMD_CURSOR, false);
qxl_release_fence_buffer_objects(release);
+ qxl_push_cursor_ring_release(qdev, release, QXL_CMD_CURSOR, false);
return ret;
@@ -665,8 +665,8 @@ static void qxl_cursor_atomic_update(str
cmd->u.position.y = plane->state->crtc_y + fb->hot_y;
qxl_release_unmap(qdev, release, &cmd->release_info);
- qxl_push_cursor_ring_release(qdev, release, QXL_CMD_CURSOR, false);
qxl_release_fence_buffer_objects(release);
+ qxl_push_cursor_ring_release(qdev, release, QXL_CMD_CURSOR, false);
if (old_cursor_bo != NULL)
qxl_bo_unpin(old_cursor_bo);
@@ -713,8 +713,8 @@ static void qxl_cursor_atomic_disable(st
cmd->type = QXL_CURSOR_HIDE;
qxl_release_unmap(qdev, release, &cmd->release_info);
- qxl_push_cursor_ring_release(qdev, release, QXL_CMD_CURSOR, false);
qxl_release_fence_buffer_objects(release);
+ qxl_push_cursor_ring_release(qdev, release, QXL_CMD_CURSOR, false);
}
static void qxl_update_dumb_head(struct qxl_device *qdev,
--- a/drivers/gpu/drm/qxl/qxl_draw.c
+++ b/drivers/gpu/drm/qxl/qxl_draw.c
@@ -243,8 +243,8 @@ void qxl_draw_dirty_fb(struct qxl_device
}
qxl_bo_kunmap(clips_bo);
- qxl_push_command_ring_release(qdev, release, QXL_CMD_DRAW, false);
qxl_release_fence_buffer_objects(release);
+ qxl_push_command_ring_release(qdev, release, QXL_CMD_DRAW, false);
out_release_backoff:
if (ret)
--- a/drivers/gpu/drm/qxl/qxl_ioctl.c
+++ b/drivers/gpu/drm/qxl/qxl_ioctl.c
@@ -261,11 +261,8 @@ static int qxl_process_single_command(st
apply_surf_reloc(qdev, &reloc_info[i]);
}
+ qxl_release_fence_buffer_objects(release);
ret = qxl_push_command_ring_release(qdev, release, cmd->type, true);
- if (ret)
- qxl_release_backoff_reserve_list(release);
- else
- qxl_release_fence_buffer_objects(release);
out_free_bos:
out_free_release:
^ permalink raw reply [flat|nested] 62+ messages in thread* [PATCH 5.4 07/57] NFSv4.1: fix handling of backchannel binding in BIND_CONN_TO_SESSION
2020-05-04 17:57 [PATCH 5.4 00/57] 5.4.39-rc1 review Greg Kroah-Hartman
` (5 preceding siblings ...)
2020-05-04 17:57 ` [PATCH 5.4 06/57] drm/qxl: qxl_release use after free Greg Kroah-Hartman
@ 2020-05-04 17:57 ` Greg Kroah-Hartman
2020-05-04 17:57 ` [PATCH 5.4 08/57] btrfs: fix transaction leak in btrfs_recover_relocation Greg Kroah-Hartman
` (53 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: Greg Kroah-Hartman @ 2020-05-04 17:57 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Olga Kornievskaia, Trond Myklebust
From: Olga Kornievskaia <olga.kornievskaia@gmail.com>
commit dff58530c4ca8ce7ee5a74db431c6e35362cf682 upstream.
Currently, if the client sends BIND_CONN_TO_SESSION with
NFS4_CDFC4_FORE_OR_BOTH but only gets NFS4_CDFS4_FORE back it ignores
that it wasn't able to enable a backchannel.
To make sure, the client sends BIND_CONN_TO_SESSION as the first
operation on the connections (ie., no other session compounds haven't
been sent before), and if the client's request to bind the backchannel
is not satisfied, then reset the connection and retry.
Cc: stable@vger.kernel.org
Signed-off-by: Olga Kornievskaia <kolga@netapp.com>
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/nfs/nfs4proc.c | 8 ++++++++
include/linux/nfs_xdr.h | 2 ++
include/linux/sunrpc/clnt.h | 5 +++++
3 files changed, 15 insertions(+)
--- a/fs/nfs/nfs4proc.c
+++ b/fs/nfs/nfs4proc.c
@@ -7852,6 +7852,7 @@ static void
nfs4_bind_one_conn_to_session_done(struct rpc_task *task, void *calldata)
{
struct nfs41_bind_conn_to_session_args *args = task->tk_msg.rpc_argp;
+ struct nfs41_bind_conn_to_session_res *res = task->tk_msg.rpc_resp;
struct nfs_client *clp = args->client;
switch (task->tk_status) {
@@ -7860,6 +7861,12 @@ nfs4_bind_one_conn_to_session_done(struc
nfs4_schedule_session_recovery(clp->cl_session,
task->tk_status);
}
+ if (args->dir == NFS4_CDFC4_FORE_OR_BOTH &&
+ res->dir != NFS4_CDFS4_BOTH) {
+ rpc_task_close_connection(task);
+ if (args->retries++ < MAX_BIND_CONN_TO_SESSION_RETRIES)
+ rpc_restart_call(task);
+ }
}
static const struct rpc_call_ops nfs4_bind_one_conn_to_session_ops = {
@@ -7882,6 +7889,7 @@ int nfs4_proc_bind_one_conn_to_session(s
struct nfs41_bind_conn_to_session_args args = {
.client = clp,
.dir = NFS4_CDFC4_FORE_OR_BOTH,
+ .retries = 0,
};
struct nfs41_bind_conn_to_session_res res;
struct rpc_message msg = {
--- a/include/linux/nfs_xdr.h
+++ b/include/linux/nfs_xdr.h
@@ -1307,11 +1307,13 @@ struct nfs41_impl_id {
struct nfstime4 date;
};
+#define MAX_BIND_CONN_TO_SESSION_RETRIES 3
struct nfs41_bind_conn_to_session_args {
struct nfs_client *client;
struct nfs4_sessionid sessionid;
u32 dir;
bool use_conn_in_rdma_mode;
+ int retries;
};
struct nfs41_bind_conn_to_session_res {
--- a/include/linux/sunrpc/clnt.h
+++ b/include/linux/sunrpc/clnt.h
@@ -237,5 +237,10 @@ static inline int rpc_reply_expected(str
(task->tk_msg.rpc_proc->p_decode != NULL);
}
+static inline void rpc_task_close_connection(struct rpc_task *task)
+{
+ if (task->tk_xprt)
+ xprt_force_disconnect(task->tk_xprt);
+}
#endif /* __KERNEL__ */
#endif /* _LINUX_SUNRPC_CLNT_H */
^ permalink raw reply [flat|nested] 62+ messages in thread* [PATCH 5.4 08/57] btrfs: fix transaction leak in btrfs_recover_relocation
2020-05-04 17:57 [PATCH 5.4 00/57] 5.4.39-rc1 review Greg Kroah-Hartman
` (6 preceding siblings ...)
2020-05-04 17:57 ` [PATCH 5.4 07/57] NFSv4.1: fix handling of backchannel binding in BIND_CONN_TO_SESSION Greg Kroah-Hartman
@ 2020-05-04 17:57 ` Greg Kroah-Hartman
2020-05-04 17:57 ` [PATCH 5.4 09/57] btrfs: fix block group leak when removing fails Greg Kroah-Hartman
` (52 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: Greg Kroah-Hartman @ 2020-05-04 17:57 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Filipe Manana, Xiyu Yang, Xin Tan,
David Sterba
From: Xiyu Yang <xiyuyang19@fudan.edu.cn>
commit 1402d17dfd9657be0da8458b2079d03c2d61c86a upstream.
btrfs_recover_relocation() invokes btrfs_join_transaction(), which joins
a btrfs_trans_handle object into transactions and returns a reference of
it with increased refcount to "trans".
When btrfs_recover_relocation() returns, "trans" becomes invalid, so the
refcount should be decreased to keep refcount balanced.
The reference counting issue happens in one exception handling path of
btrfs_recover_relocation(). When read_fs_root() failed, the refcnt
increased by btrfs_join_transaction() is not decreased, causing a refcnt
leak.
Fix this issue by calling btrfs_end_transaction() on this error path
when read_fs_root() failed.
Fixes: 79787eaab461 ("btrfs: replace many BUG_ONs with proper error handling")
CC: stable@vger.kernel.org # 4.4+
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Xiyu Yang <xiyuyang19@fudan.edu.cn>
Signed-off-by: Xin Tan <tanxin.ctf@gmail.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/btrfs/relocation.c | 1 +
1 file changed, 1 insertion(+)
--- a/fs/btrfs/relocation.c
+++ b/fs/btrfs/relocation.c
@@ -4605,6 +4605,7 @@ int btrfs_recover_relocation(struct btrf
if (IS_ERR(fs_root)) {
err = PTR_ERR(fs_root);
list_add_tail(&reloc_root->root_list, &reloc_roots);
+ btrfs_end_transaction(trans);
goto out_unset;
}
^ permalink raw reply [flat|nested] 62+ messages in thread* [PATCH 5.4 09/57] btrfs: fix block group leak when removing fails
2020-05-04 17:57 [PATCH 5.4 00/57] 5.4.39-rc1 review Greg Kroah-Hartman
` (7 preceding siblings ...)
2020-05-04 17:57 ` [PATCH 5.4 08/57] btrfs: fix transaction leak in btrfs_recover_relocation Greg Kroah-Hartman
@ 2020-05-04 17:57 ` Greg Kroah-Hartman
2020-05-04 17:57 ` [PATCH 5.4 10/57] btrfs: fix partial loss of prealloc extent past i_size after fsync Greg Kroah-Hartman
` (51 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: Greg Kroah-Hartman @ 2020-05-04 17:57 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Xiyu Yang, Xin Tan, David Sterba
From: Xiyu Yang <xiyuyang19@fudan.edu.cn>
commit f6033c5e333238f299c3ae03fac8cc1365b23b77 upstream.
btrfs_remove_block_group() invokes btrfs_lookup_block_group(), which
returns a local reference of the block group that contains the given
bytenr to "block_group" with increased refcount.
When btrfs_remove_block_group() returns, "block_group" becomes invalid,
so the refcount should be decreased to keep refcount balanced.
The reference counting issue happens in several exception handling paths
of btrfs_remove_block_group(). When those error scenarios occur such as
btrfs_alloc_path() returns NULL, the function forgets to decrease its
refcnt increased by btrfs_lookup_block_group() and will cause a refcnt
leak.
Fix this issue by jumping to "out_put_group" label and calling
btrfs_put_block_group() when those error scenarios occur.
CC: stable@vger.kernel.org # 4.4+
Signed-off-by: Xiyu Yang <xiyuyang19@fudan.edu.cn>
Signed-off-by: Xin Tan <tanxin.ctf@gmail.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/btrfs/block-group.c | 16 ++++++++++------
1 file changed, 10 insertions(+), 6 deletions(-)
--- a/fs/btrfs/block-group.c
+++ b/fs/btrfs/block-group.c
@@ -910,7 +910,7 @@ int btrfs_remove_block_group(struct btrf
path = btrfs_alloc_path();
if (!path) {
ret = -ENOMEM;
- goto out;
+ goto out_put_group;
}
/*
@@ -948,7 +948,7 @@ int btrfs_remove_block_group(struct btrf
ret = btrfs_orphan_add(trans, BTRFS_I(inode));
if (ret) {
btrfs_add_delayed_iput(inode);
- goto out;
+ goto out_put_group;
}
clear_nlink(inode);
/* One for the block groups ref */
@@ -971,13 +971,13 @@ int btrfs_remove_block_group(struct btrf
ret = btrfs_search_slot(trans, tree_root, &key, path, -1, 1);
if (ret < 0)
- goto out;
+ goto out_put_group;
if (ret > 0)
btrfs_release_path(path);
if (ret == 0) {
ret = btrfs_del_item(trans, tree_root, path);
if (ret)
- goto out;
+ goto out_put_group;
btrfs_release_path(path);
}
@@ -1094,9 +1094,9 @@ int btrfs_remove_block_group(struct btrf
ret = remove_block_group_free_space(trans, block_group);
if (ret)
- goto out;
+ goto out_put_group;
- btrfs_put_block_group(block_group);
+ /* Once for the block groups rbtree */
btrfs_put_block_group(block_group);
ret = btrfs_search_slot(trans, root, &key, path, -1, 1);
@@ -1119,6 +1119,10 @@ int btrfs_remove_block_group(struct btrf
/* once for the tree */
free_extent_map(em);
}
+
+out_put_group:
+ /* Once for the lookup reference */
+ btrfs_put_block_group(block_group);
out:
if (remove_rsv)
btrfs_delayed_refs_rsv_release(fs_info, 1);
^ permalink raw reply [flat|nested] 62+ messages in thread* [PATCH 5.4 10/57] btrfs: fix partial loss of prealloc extent past i_size after fsync
2020-05-04 17:57 [PATCH 5.4 00/57] 5.4.39-rc1 review Greg Kroah-Hartman
` (8 preceding siblings ...)
2020-05-04 17:57 ` [PATCH 5.4 09/57] btrfs: fix block group leak when removing fails Greg Kroah-Hartman
@ 2020-05-04 17:57 ` Greg Kroah-Hartman
2020-05-04 17:57 ` [PATCH 5.4 11/57] btrfs: transaction: Avoid deadlock due to bad initialization timing of fs_info::journal_info Greg Kroah-Hartman
` (50 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: Greg Kroah-Hartman @ 2020-05-04 17:57 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Filipe Manana, David Sterba
From: Filipe Manana <fdmanana@suse.com>
commit f135cea30de5f74d5bfb5116682073841fb4af8f upstream.
When we have an inode with a prealloc extent that starts at an offset
lower than the i_size and there is another prealloc extent that starts at
an offset beyond i_size, we can end up losing part of the first prealloc
extent (the part that starts at i_size) and have an implicit hole if we
fsync the file and then have a power failure.
Consider the following example with comments explaining how and why it
happens.
$ mkfs.btrfs -f /dev/sdb
$ mount /dev/sdb /mnt
# Create our test file with 2 consecutive prealloc extents, each with a
# size of 128Kb, and covering the range from 0 to 256Kb, with a file
# size of 0.
$ xfs_io -f -c "falloc -k 0 128K" /mnt/foo
$ xfs_io -c "falloc -k 128K 128K" /mnt/foo
# Fsync the file to record both extents in the log tree.
$ xfs_io -c "fsync" /mnt/foo
# Now do a redudant extent allocation for the range from 0 to 64Kb.
# This will merely increase the file size from 0 to 64Kb. Instead we
# could also do a truncate to set the file size to 64Kb.
$ xfs_io -c "falloc 0 64K" /mnt/foo
# Fsync the file, so we update the inode item in the log tree with the
# new file size (64Kb). This also ends up setting the number of bytes
# for the first prealloc extent to 64Kb. This is done by the truncation
# at btrfs_log_prealloc_extents().
# This means that if a power failure happens after this, a write into
# the file range 64Kb to 128Kb will not use the prealloc extent and
# will result in allocation of a new extent.
$ xfs_io -c "fsync" /mnt/foo
# Now set the file size to 256K with a truncate and then fsync the file.
# Since no changes happened to the extents, the fsync only updates the
# i_size in the inode item at the log tree. This results in an implicit
# hole for the file range from 64Kb to 128Kb, something which fsck will
# complain when not using the NO_HOLES feature if we replay the log
# after a power failure.
$ xfs_io -c "truncate 256K" -c "fsync" /mnt/foo
So instead of always truncating the log to the inode's current i_size at
btrfs_log_prealloc_extents(), check first if there's a prealloc extent
that starts at an offset lower than the i_size and with a length that
crosses the i_size - if there is one, just make sure we truncate to a
size that corresponds to the end offset of that prealloc extent, so
that we don't lose the part of that extent that starts at i_size if a
power failure happens.
A test case for fstests follows soon.
Fixes: 31d11b83b96f ("Btrfs: fix duplicate extents after fsync of file with prealloc extents")
CC: stable@vger.kernel.org # 4.14+
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/btrfs/tree-log.c | 43 ++++++++++++++++++++++++++++++++++++++++---
1 file changed, 40 insertions(+), 3 deletions(-)
--- a/fs/btrfs/tree-log.c
+++ b/fs/btrfs/tree-log.c
@@ -4242,6 +4242,9 @@ static int btrfs_log_prealloc_extents(st
const u64 ino = btrfs_ino(inode);
struct btrfs_path *dst_path = NULL;
bool dropped_extents = false;
+ u64 truncate_offset = i_size;
+ struct extent_buffer *leaf;
+ int slot;
int ins_nr = 0;
int start_slot;
int ret;
@@ -4256,9 +4259,43 @@ static int btrfs_log_prealloc_extents(st
if (ret < 0)
goto out;
+ /*
+ * We must check if there is a prealloc extent that starts before the
+ * i_size and crosses the i_size boundary. This is to ensure later we
+ * truncate down to the end of that extent and not to the i_size, as
+ * otherwise we end up losing part of the prealloc extent after a log
+ * replay and with an implicit hole if there is another prealloc extent
+ * that starts at an offset beyond i_size.
+ */
+ ret = btrfs_previous_item(root, path, ino, BTRFS_EXTENT_DATA_KEY);
+ if (ret < 0)
+ goto out;
+
+ if (ret == 0) {
+ struct btrfs_file_extent_item *ei;
+
+ leaf = path->nodes[0];
+ slot = path->slots[0];
+ ei = btrfs_item_ptr(leaf, slot, struct btrfs_file_extent_item);
+
+ if (btrfs_file_extent_type(leaf, ei) ==
+ BTRFS_FILE_EXTENT_PREALLOC) {
+ u64 extent_end;
+
+ btrfs_item_key_to_cpu(leaf, &key, slot);
+ extent_end = key.offset +
+ btrfs_file_extent_num_bytes(leaf, ei);
+
+ if (extent_end > i_size)
+ truncate_offset = extent_end;
+ }
+ } else {
+ ret = 0;
+ }
+
while (true) {
- struct extent_buffer *leaf = path->nodes[0];
- int slot = path->slots[0];
+ leaf = path->nodes[0];
+ slot = path->slots[0];
if (slot >= btrfs_header_nritems(leaf)) {
if (ins_nr > 0) {
@@ -4296,7 +4333,7 @@ static int btrfs_log_prealloc_extents(st
ret = btrfs_truncate_inode_items(trans,
root->log_root,
&inode->vfs_inode,
- i_size,
+ truncate_offset,
BTRFS_EXTENT_DATA_KEY);
} while (ret == -EAGAIN);
if (ret)
^ permalink raw reply [flat|nested] 62+ messages in thread* [PATCH 5.4 11/57] btrfs: transaction: Avoid deadlock due to bad initialization timing of fs_info::journal_info
2020-05-04 17:57 [PATCH 5.4 00/57] 5.4.39-rc1 review Greg Kroah-Hartman
` (9 preceding siblings ...)
2020-05-04 17:57 ` [PATCH 5.4 10/57] btrfs: fix partial loss of prealloc extent past i_size after fsync Greg Kroah-Hartman
@ 2020-05-04 17:57 ` Greg Kroah-Hartman
2020-05-04 17:57 ` [PATCH 5.4 12/57] mmc: cqhci: Avoid false "cqhci: CQE stuck on" by not open-coding timeout loop Greg Kroah-Hartman
` (49 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: Greg Kroah-Hartman @ 2020-05-04 17:57 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Qu Wenruo, David Sterba
From: Qu Wenruo <wqu@suse.com>
commit fcc99734d1d4ced30167eb02e17f656735cb9928 upstream.
[BUG]
One run of btrfs/063 triggered the following lockdep warning:
============================================
WARNING: possible recursive locking detected
5.6.0-rc7-custom+ #48 Not tainted
--------------------------------------------
kworker/u24:0/7 is trying to acquire lock:
ffff88817d3a46e0 (sb_internal#2){.+.+}, at: start_transaction+0x66c/0x890 [btrfs]
but task is already holding lock:
ffff88817d3a46e0 (sb_internal#2){.+.+}, at: start_transaction+0x66c/0x890 [btrfs]
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock(sb_internal#2);
lock(sb_internal#2);
*** DEADLOCK ***
May be due to missing lock nesting notation
4 locks held by kworker/u24:0/7:
#0: ffff88817b495948 ((wq_completion)btrfs-endio-write){+.+.}, at: process_one_work+0x557/0xb80
#1: ffff888189ea7db8 ((work_completion)(&work->normal_work)){+.+.}, at: process_one_work+0x557/0xb80
#2: ffff88817d3a46e0 (sb_internal#2){.+.+}, at: start_transaction+0x66c/0x890 [btrfs]
#3: ffff888174ca4da8 (&fs_info->reloc_mutex){+.+.}, at: btrfs_record_root_in_trans+0x83/0xd0 [btrfs]
stack backtrace:
CPU: 0 PID: 7 Comm: kworker/u24:0 Not tainted 5.6.0-rc7-custom+ #48
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015
Workqueue: btrfs-endio-write btrfs_work_helper [btrfs]
Call Trace:
dump_stack+0xc2/0x11a
__lock_acquire.cold+0xce/0x214
lock_acquire+0xe6/0x210
__sb_start_write+0x14e/0x290
start_transaction+0x66c/0x890 [btrfs]
btrfs_join_transaction+0x1d/0x20 [btrfs]
find_free_extent+0x1504/0x1a50 [btrfs]
btrfs_reserve_extent+0xd5/0x1f0 [btrfs]
btrfs_alloc_tree_block+0x1ac/0x570 [btrfs]
btrfs_copy_root+0x213/0x580 [btrfs]
create_reloc_root+0x3bd/0x470 [btrfs]
btrfs_init_reloc_root+0x2d2/0x310 [btrfs]
record_root_in_trans+0x191/0x1d0 [btrfs]
btrfs_record_root_in_trans+0x90/0xd0 [btrfs]
start_transaction+0x16e/0x890 [btrfs]
btrfs_join_transaction+0x1d/0x20 [btrfs]
btrfs_finish_ordered_io+0x55d/0xcd0 [btrfs]
finish_ordered_fn+0x15/0x20 [btrfs]
btrfs_work_helper+0x116/0x9a0 [btrfs]
process_one_work+0x632/0xb80
worker_thread+0x80/0x690
kthread+0x1a3/0x1f0
ret_from_fork+0x27/0x50
It's pretty hard to reproduce, only one hit so far.
[CAUSE]
This is because we're calling btrfs_join_transaction() without re-using
the current running one:
btrfs_finish_ordered_io()
|- btrfs_join_transaction() <<< Call #1
|- btrfs_record_root_in_trans()
|- btrfs_reserve_extent()
|- btrfs_join_transaction() <<< Call #2
Normally such btrfs_join_transaction() call should re-use the existing
one, without trying to re-start a transaction.
But the problem is, in btrfs_join_transaction() call #1, we call
btrfs_record_root_in_trans() before initializing current::journal_info.
And in btrfs_join_transaction() call #2, we're relying on
current::journal_info to avoid such deadlock.
[FIX]
Call btrfs_record_root_in_trans() after we have initialized
current::journal_info.
CC: stable@vger.kernel.org # 4.4+
Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/btrfs/transaction.c | 13 +++++++++++--
1 file changed, 11 insertions(+), 2 deletions(-)
--- a/fs/btrfs/transaction.c
+++ b/fs/btrfs/transaction.c
@@ -590,10 +590,19 @@ again:
}
got_it:
- btrfs_record_root_in_trans(h, root);
-
if (!current->journal_info)
current->journal_info = h;
+
+ /*
+ * btrfs_record_root_in_trans() needs to alloc new extents, and may
+ * call btrfs_join_transaction() while we're also starting a
+ * transaction.
+ *
+ * Thus it need to be called after current->journal_info initialized,
+ * or we can deadlock.
+ */
+ btrfs_record_root_in_trans(h, root);
+
return h;
join_fail:
^ permalink raw reply [flat|nested] 62+ messages in thread* [PATCH 5.4 12/57] mmc: cqhci: Avoid false "cqhci: CQE stuck on" by not open-coding timeout loop
2020-05-04 17:57 [PATCH 5.4 00/57] 5.4.39-rc1 review Greg Kroah-Hartman
` (10 preceding siblings ...)
2020-05-04 17:57 ` [PATCH 5.4 11/57] btrfs: transaction: Avoid deadlock due to bad initialization timing of fs_info::journal_info Greg Kroah-Hartman
@ 2020-05-04 17:57 ` Greg Kroah-Hartman
2020-05-04 17:57 ` [PATCH 5.4 13/57] mmc: sdhci-xenon: fix annoying 1.8V regulator warning Greg Kroah-Hartman
` (48 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: Greg Kroah-Hartman @ 2020-05-04 17:57 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Douglas Anderson, Adrian Hunter, Ulf Hansson
From: Douglas Anderson <dianders@chromium.org>
commit b1ac62a7ac386d76968af5f374a4a7a82a35fe31 upstream.
Open-coding a timeout loop invariably leads to errors with handling
the timeout properly in one corner case or another. In the case of
cqhci we might report "CQE stuck on" even if it wasn't stuck on.
You'd just need this sequence of events to happen in cqhci_off():
1. Call ktime_get().
2. Something happens to interrupt the CPU for > 100 us (context switch
or interrupt).
3. Check time and; set "timed_out" to true since > 100 us.
4. Read CQHCI_CTL.
5. Both "reg & CQHCI_HALT" and "timed_out" are true, so break.
6. Since "timed_out" is true, falsely print the error message.
Rather than fixing the polling loop, use readx_poll_timeout() like
many people do. This has been time tested to handle the corner cases.
Fixes: a4080225f51d ("mmc: cqhci: support for command queue enabled host")
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20200413162717.1.Idece266f5c8793193b57a1ddb1066d030c6af8e0@changeid
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/mmc/host/cqhci.c | 21 ++++++++++-----------
1 file changed, 10 insertions(+), 11 deletions(-)
--- a/drivers/mmc/host/cqhci.c
+++ b/drivers/mmc/host/cqhci.c
@@ -5,6 +5,7 @@
#include <linux/delay.h>
#include <linux/highmem.h>
#include <linux/io.h>
+#include <linux/iopoll.h>
#include <linux/module.h>
#include <linux/dma-mapping.h>
#include <linux/slab.h>
@@ -343,12 +344,16 @@ static int cqhci_enable(struct mmc_host
/* CQHCI is idle and should halt immediately, so set a small timeout */
#define CQHCI_OFF_TIMEOUT 100
+static u32 cqhci_read_ctl(struct cqhci_host *cq_host)
+{
+ return cqhci_readl(cq_host, CQHCI_CTL);
+}
+
static void cqhci_off(struct mmc_host *mmc)
{
struct cqhci_host *cq_host = mmc->cqe_private;
- ktime_t timeout;
- bool timed_out;
u32 reg;
+ int err;
if (!cq_host->enabled || !mmc->cqe_on || cq_host->recovery_halt)
return;
@@ -358,15 +363,9 @@ static void cqhci_off(struct mmc_host *m
cqhci_writel(cq_host, CQHCI_HALT, CQHCI_CTL);
- timeout = ktime_add_us(ktime_get(), CQHCI_OFF_TIMEOUT);
- while (1) {
- timed_out = ktime_compare(ktime_get(), timeout) > 0;
- reg = cqhci_readl(cq_host, CQHCI_CTL);
- if ((reg & CQHCI_HALT) || timed_out)
- break;
- }
-
- if (timed_out)
+ err = readx_poll_timeout(cqhci_read_ctl, cq_host, reg,
+ reg & CQHCI_HALT, 0, CQHCI_OFF_TIMEOUT);
+ if (err < 0)
pr_err("%s: cqhci: CQE stuck on\n", mmc_hostname(mmc));
else
pr_debug("%s: cqhci: CQE off\n", mmc_hostname(mmc));
^ permalink raw reply [flat|nested] 62+ messages in thread* [PATCH 5.4 13/57] mmc: sdhci-xenon: fix annoying 1.8V regulator warning
2020-05-04 17:57 [PATCH 5.4 00/57] 5.4.39-rc1 review Greg Kroah-Hartman
` (11 preceding siblings ...)
2020-05-04 17:57 ` [PATCH 5.4 12/57] mmc: cqhci: Avoid false "cqhci: CQE stuck on" by not open-coding timeout loop Greg Kroah-Hartman
@ 2020-05-04 17:57 ` Greg Kroah-Hartman
2020-05-04 17:57 ` [PATCH 5.4 14/57] mmc: sdhci-pci: Fix eMMC driver strength for BYT-based controllers Greg Kroah-Hartman
` (47 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: Greg Kroah-Hartman @ 2020-05-04 17:57 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Marek Behún, Ulf Hansson
From: Marek Behún <marek.behun@nic.cz>
commit bb32e1987bc55ce1db400faf47d85891da3c9b9f upstream.
For some reason the Host Control2 register of the Xenon SDHCI controller
sometimes reports the bit representing 1.8V signaling as 0 when read
after it was written as 1. Subsequent read reports 1.
This causes the sdhci_start_signal_voltage_switch function to report
1.8V regulator output did not become stable
When CONFIG_PM is enabled, the host is suspended and resumend many
times, and in each resume the switch to 1.8V is called, and so the
kernel log reports this message annoyingly often.
Do an empty read of the Host Control2 register in Xenon's
.voltage_switch method to circumvent this.
This patch fixes this particular problem on Turris MOX.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Fixes: 8d876bf472db ("mmc: sdhci-xenon: wait 5ms after set 1.8V...")
Cc: stable@vger.kernel.org # v4.16+
Link: https://lore.kernel.org/r/20200420080444.25242-1-marek.behun@nic.cz
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/mmc/host/sdhci-xenon.c | 10 ++++++++++
1 file changed, 10 insertions(+)
--- a/drivers/mmc/host/sdhci-xenon.c
+++ b/drivers/mmc/host/sdhci-xenon.c
@@ -235,6 +235,16 @@ static void xenon_voltage_switch(struct
{
/* Wait for 5ms after set 1.8V signal enable bit */
usleep_range(5000, 5500);
+
+ /*
+ * For some reason the controller's Host Control2 register reports
+ * the bit representing 1.8V signaling as 0 when read after it was
+ * written as 1. Subsequent read reports 1.
+ *
+ * Since this may cause some issues, do an empty read of the Host
+ * Control2 register here to circumvent this.
+ */
+ sdhci_readw(host, SDHCI_HOST_CONTROL2);
}
static const struct sdhci_ops sdhci_xenon_ops = {
^ permalink raw reply [flat|nested] 62+ messages in thread* [PATCH 5.4 14/57] mmc: sdhci-pci: Fix eMMC driver strength for BYT-based controllers
2020-05-04 17:57 [PATCH 5.4 00/57] 5.4.39-rc1 review Greg Kroah-Hartman
` (12 preceding siblings ...)
2020-05-04 17:57 ` [PATCH 5.4 13/57] mmc: sdhci-xenon: fix annoying 1.8V regulator warning Greg Kroah-Hartman
@ 2020-05-04 17:57 ` Greg Kroah-Hartman
2020-05-04 17:57 ` [PATCH 5.4 15/57] mmc: sdhci-msm: Enable host capabilities pertains to R1b response Greg Kroah-Hartman
` (46 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: Greg Kroah-Hartman @ 2020-05-04 17:57 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Adrian Hunter, Ulf Hansson
From: Adrian Hunter <adrian.hunter@intel.com>
commit 1a8eb6b373c2af6533c13d1ea11f504e5010ed9a upstream.
BIOS writers have begun the practice of setting 40 ohm eMMC driver strength
even though the eMMC may not support it, on the assumption that the kernel
will validate the value against the eMMC (Extended CSD DRIVER_STRENGTH
[offset 197]) and revert to the default 50 ohm value if 40 ohm is invalid.
This is done to avoid changing the value for different boards.
Putting aside the merits of this approach, it is clear the eMMC's mask
of supported driver strengths is more reliable than the value provided
by BIOS. Add validation accordingly.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Fixes: 51ced59cc02e ("mmc: sdhci-pci: Use ACPI DSM to get driver strength for some Intel devices")
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20200422111629.4899-1-adrian.hunter@intel.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/mmc/host/sdhci-pci-core.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/mmc/host/sdhci-pci-core.c
+++ b/drivers/mmc/host/sdhci-pci-core.c
@@ -601,6 +601,9 @@ static int intel_select_drive_strength(s
struct sdhci_pci_slot *slot = sdhci_priv(host);
struct intel_host *intel_host = sdhci_pci_priv(slot);
+ if (!(mmc_driver_type_mask(intel_host->drv_strength) & card_drv))
+ return 0;
+
return intel_host->drv_strength;
}
^ permalink raw reply [flat|nested] 62+ messages in thread* [PATCH 5.4 15/57] mmc: sdhci-msm: Enable host capabilities pertains to R1b response
2020-05-04 17:57 [PATCH 5.4 00/57] 5.4.39-rc1 review Greg Kroah-Hartman
` (13 preceding siblings ...)
2020-05-04 17:57 ` [PATCH 5.4 14/57] mmc: sdhci-pci: Fix eMMC driver strength for BYT-based controllers Greg Kroah-Hartman
@ 2020-05-04 17:57 ` Greg Kroah-Hartman
2020-05-04 17:57 ` [PATCH 5.4 16/57] mmc: meson-mx-sdio: Set MMC_CAP_WAIT_WHILE_BUSY Greg Kroah-Hartman
` (45 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: Greg Kroah-Hartman @ 2020-05-04 17:57 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Veerabhadrarao Badiganti,
Adrian Hunter, Ulf Hansson
From: Veerabhadrarao Badiganti <vbadigan@codeaurora.org>
commit 9d8cb58691f85cef687512262acb2c7109ee4868 upstream.
MSM sd host controller is capable of HW busy detection of device busy
signaling over DAT0 line. And it requires the R1B response for commands
that have this response associated with them.
So set the below two host capabilities for qcom SDHC.
- MMC_CAP_WAIT_WHILE_BUSY
- MMC_CAP_NEED_RSP_BUSY
Recent development of the mmc core in regards to this, revealed this as
being a potential bug, hence the stable tag.
Cc: <stable@vger.kernel.org> # v4.19+
Signed-off-by: Veerabhadrarao Badiganti <vbadigan@codeaurora.org>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Link: https://lore.kernel.org/r/1587363626-20413-2-git-send-email-vbadigan@codeaurora.org
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/mmc/host/sdhci-msm.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/mmc/host/sdhci-msm.c
+++ b/drivers/mmc/host/sdhci-msm.c
@@ -1944,6 +1944,8 @@ static int sdhci_msm_probe(struct platfo
goto clk_disable;
}
+ msm_host->mmc->caps |= MMC_CAP_WAIT_WHILE_BUSY | MMC_CAP_NEED_RSP_BUSY;
+
pm_runtime_get_noresume(&pdev->dev);
pm_runtime_set_active(&pdev->dev);
pm_runtime_enable(&pdev->dev);
^ permalink raw reply [flat|nested] 62+ messages in thread* [PATCH 5.4 16/57] mmc: meson-mx-sdio: Set MMC_CAP_WAIT_WHILE_BUSY
2020-05-04 17:57 [PATCH 5.4 00/57] 5.4.39-rc1 review Greg Kroah-Hartman
` (14 preceding siblings ...)
2020-05-04 17:57 ` [PATCH 5.4 15/57] mmc: sdhci-msm: Enable host capabilities pertains to R1b response Greg Kroah-Hartman
@ 2020-05-04 17:57 ` Greg Kroah-Hartman
2020-05-04 17:57 ` [PATCH 5.4 17/57] mmc: meson-mx-sdio: remove the broken ->card_busy() op Greg Kroah-Hartman
` (44 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: Greg Kroah-Hartman @ 2020-05-04 17:57 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Martin Blumenstingl, Ulf Hansson
From: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
commit e53b868b3cf5beeaa2f851ec6740112bf4d6a8cb upstream.
The Meson SDIO controller uses the DAT0 lane for hardware busy
detection. Set MMC_CAP_WAIT_WHILE_BUSY accordingly. This fixes
the following error observed with Linux 5.7 (pre-rc-1):
mmc1: Card stuck being busy! __mmc_poll_for_busy
blk_update_request: I/O error, dev mmcblk1, sector 17111080 op
0x3:(DISCARD) flags 0x0 phys_seg 1 prio class 0
Fixes: ed80a13bb4c4c9 ("mmc: meson-mx-sdio: Add a driver for the Amlogic Meson8 and Meson8b SoCs")
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20200416183513.993763-2-martin.blumenstingl@googlemail.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/mmc/host/meson-mx-sdio.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/mmc/host/meson-mx-sdio.c
+++ b/drivers/mmc/host/meson-mx-sdio.c
@@ -570,7 +570,7 @@ static int meson_mx_mmc_add_host(struct
mmc->f_max = clk_round_rate(host->cfg_div_clk,
clk_get_rate(host->parent_clk));
- mmc->caps |= MMC_CAP_ERASE | MMC_CAP_CMD23;
+ mmc->caps |= MMC_CAP_ERASE | MMC_CAP_CMD23 | MMC_CAP_WAIT_WHILE_BUSY;
mmc->ops = &meson_mx_mmc_ops;
ret = mmc_of_parse(mmc);
^ permalink raw reply [flat|nested] 62+ messages in thread* [PATCH 5.4 17/57] mmc: meson-mx-sdio: remove the broken ->card_busy() op
2020-05-04 17:57 [PATCH 5.4 00/57] 5.4.39-rc1 review Greg Kroah-Hartman
` (15 preceding siblings ...)
2020-05-04 17:57 ` [PATCH 5.4 16/57] mmc: meson-mx-sdio: Set MMC_CAP_WAIT_WHILE_BUSY Greg Kroah-Hartman
@ 2020-05-04 17:57 ` Greg Kroah-Hartman
2020-05-04 17:57 ` [PATCH 5.4 18/57] crypto: caam - fix the address of the last entry of S/G Greg Kroah-Hartman
` (43 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: Greg Kroah-Hartman @ 2020-05-04 17:57 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Martin Blumenstingl, Ulf Hansson
From: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
commit ddca1092c4324c89cf692b5efe655aa251864b51 upstream.
The recent commit 0d84c3e6a5b2 ("mmc: core: Convert to
mmc_poll_for_busy() for erase/trim/discard") makes use of the
->card_busy() op for SD cards. This uncovered that the ->card_busy() op
in the Meson SDIO driver was never working right:
while polling the busy status with ->card_busy()
meson_mx_mmc_card_busy() reads only one of the two MESON_MX_SDIO_IRQC
register values 0x1f001f10 or 0x1f003f10. This translates to "three out
of four DAT lines are HIGH" and "all four DAT lines are HIGH", which
is interpreted as "the card is busy".
It turns out that no situation can be observed where all four DAT lines
are LOW, meaning the card is not busy anymore. Upon further research the
3.10 vendor driver for this controller does not implement the
->card_busy() op.
Remove the ->card_busy() op from the meson-mx-sdio driver since it is
not working. At the time of writing this patch it is not clear what's
needed to make the ->card_busy() implementation work with this specific
controller hardware. For all use-cases which have previously worked the
MMC_CAP_WAIT_WHILE_BUSY flag is now taking over, even if we don't have
a ->card_busy() op anymore.
Fixes: ed80a13bb4c4c9 ("mmc: meson-mx-sdio: Add a driver for the Amlogic Meson8 and Meson8b SoCs")
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20200416183513.993763-3-martin.blumenstingl@googlemail.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/mmc/host/meson-mx-sdio.c | 9 ---------
1 file changed, 9 deletions(-)
--- a/drivers/mmc/host/meson-mx-sdio.c
+++ b/drivers/mmc/host/meson-mx-sdio.c
@@ -357,14 +357,6 @@ static void meson_mx_mmc_request(struct
meson_mx_mmc_start_cmd(mmc, mrq->cmd);
}
-static int meson_mx_mmc_card_busy(struct mmc_host *mmc)
-{
- struct meson_mx_mmc_host *host = mmc_priv(mmc);
- u32 irqc = readl(host->base + MESON_MX_SDIO_IRQC);
-
- return !!(irqc & MESON_MX_SDIO_IRQC_FORCE_DATA_DAT_MASK);
-}
-
static void meson_mx_mmc_read_response(struct mmc_host *mmc,
struct mmc_command *cmd)
{
@@ -506,7 +498,6 @@ static void meson_mx_mmc_timeout(struct
static struct mmc_host_ops meson_mx_mmc_ops = {
.request = meson_mx_mmc_request,
.set_ios = meson_mx_mmc_set_ios,
- .card_busy = meson_mx_mmc_card_busy,
.get_cd = mmc_gpio_get_cd,
.get_ro = mmc_gpio_get_ro,
};
^ permalink raw reply [flat|nested] 62+ messages in thread* [PATCH 5.4 18/57] crypto: caam - fix the address of the last entry of S/G
2020-05-04 17:57 [PATCH 5.4 00/57] 5.4.39-rc1 review Greg Kroah-Hartman
` (16 preceding siblings ...)
2020-05-04 17:57 ` [PATCH 5.4 17/57] mmc: meson-mx-sdio: remove the broken ->card_busy() op Greg Kroah-Hartman
@ 2020-05-04 17:57 ` Greg Kroah-Hartman
2020-05-04 17:57 ` [PATCH 5.4 19/57] ALSA: hda/realtek - Two front mics on a Lenovo ThinkCenter Greg Kroah-Hartman
` (42 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: Greg Kroah-Hartman @ 2020-05-04 17:57 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Iuliana Prodan, Horia Geantă,
Herbert Xu
From: Iuliana Prodan <iuliana.prodan@nxp.com>
commit 55b3209acbb01cb02b1ee6b1afe80d83b1aab36d upstream.
For skcipher algorithms, the input, output HW S/G tables
look like this: [IV, src][dst, IV]
Now, we can have 2 conditions here:
- there is no IV;
- src and dst are equal (in-place encryption) and scattered
and the error is an "off-by-one" in the HW S/G table.
This issue was seen with KASAN:
BUG: KASAN: slab-out-of-bounds in skcipher_edesc_alloc+0x95c/0x1018
Read of size 4 at addr ffff000022a02958 by task cryptomgr_test/321
CPU: 2 PID: 321 Comm: cryptomgr_test Not tainted
5.6.0-rc1-00165-ge4ef8383-dirty #4
Hardware name: LS1046A RDB Board (DT)
Call trace:
dump_backtrace+0x0/0x260
show_stack+0x14/0x20
dump_stack+0xe8/0x144
print_address_description.isra.11+0x64/0x348
__kasan_report+0x11c/0x230
kasan_report+0xc/0x18
__asan_load4+0x90/0xb0
skcipher_edesc_alloc+0x95c/0x1018
skcipher_encrypt+0x84/0x150
crypto_skcipher_encrypt+0x50/0x68
test_skcipher_vec_cfg+0x4d4/0xc10
test_skcipher_vec+0x178/0x1d8
alg_test_skcipher+0xec/0x230
alg_test.part.44+0x114/0x4a0
alg_test+0x1c/0x60
cryptomgr_test+0x34/0x58
kthread+0x1b8/0x1c0
ret_from_fork+0x10/0x18
Allocated by task 321:
save_stack+0x24/0xb0
__kasan_kmalloc.isra.10+0xc4/0xe0
kasan_kmalloc+0xc/0x18
__kmalloc+0x178/0x2b8
skcipher_edesc_alloc+0x21c/0x1018
skcipher_encrypt+0x84/0x150
crypto_skcipher_encrypt+0x50/0x68
test_skcipher_vec_cfg+0x4d4/0xc10
test_skcipher_vec+0x178/0x1d8
alg_test_skcipher+0xec/0x230
alg_test.part.44+0x114/0x4a0
alg_test+0x1c/0x60
cryptomgr_test+0x34/0x58
kthread+0x1b8/0x1c0
ret_from_fork+0x10/0x18
Freed by task 0:
(stack is not available)
The buggy address belongs to the object at ffff000022a02800
which belongs to the cache dma-kmalloc-512 of size 512
The buggy address is located 344 bytes inside of
512-byte region [ffff000022a02800, ffff000022a02a00)
The buggy address belongs to the page:
page:fffffe00006a8000 refcount:1 mapcount:0 mapping:ffff00093200c400
index:0x0 compound_mapcount: 0
flags: 0xffff00000010200(slab|head)
raw: 0ffff00000010200 dead000000000100 dead000000000122 ffff00093200c400
raw: 0000000000000000 0000000080100010 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff000022a02800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffff000022a02880: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>ffff000022a02900: 00 00 00 00 00 00 00 00 00 00 fc fc fc fc fc fc
^
ffff000022a02980: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff000022a02a00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
Fixes: 334d37c9e263 ("crypto: caam - update IV using HW support")
Cc: <stable@vger.kernel.org> # v5.3+
Signed-off-by: Iuliana Prodan <iuliana.prodan@nxp.com>
Reviewed-by: Horia Geantă <horia.geanta@nxp.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/crypto/caam/caamalg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/crypto/caam/caamalg.c
+++ b/drivers/crypto/caam/caamalg.c
@@ -1810,7 +1810,7 @@ static struct skcipher_edesc *skcipher_e
if (ivsize || mapped_dst_nents > 1)
sg_to_sec4_set_last(edesc->sec4_sg + dst_sg_idx +
- mapped_dst_nents);
+ mapped_dst_nents - 1 + !!ivsize);
if (sec4_sg_bytes) {
edesc->sec4_sg_dma = dma_map_single(jrdev, edesc->sec4_sg,
^ permalink raw reply [flat|nested] 62+ messages in thread* [PATCH 5.4 19/57] ALSA: hda/realtek - Two front mics on a Lenovo ThinkCenter
2020-05-04 17:57 [PATCH 5.4 00/57] 5.4.39-rc1 review Greg Kroah-Hartman
` (17 preceding siblings ...)
2020-05-04 17:57 ` [PATCH 5.4 18/57] crypto: caam - fix the address of the last entry of S/G Greg Kroah-Hartman
@ 2020-05-04 17:57 ` Greg Kroah-Hartman
2020-05-04 17:57 ` [PATCH 5.4 20/57] ALSA: usb-audio: Correct a typo of NuPrime DAC-10 USB ID Greg Kroah-Hartman
` (41 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: Greg Kroah-Hartman @ 2020-05-04 17:57 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Hui Wang, Takashi Iwai
From: Hui Wang <hui.wang@canonical.com>
commit ef0b3203c758b6b8abdb5dca651880347eae6b8c upstream.
This new Lenovo ThinkCenter has two front mics which can't be handled
by PA so far, so apply the fixup ALC283_FIXUP_HEADSET_MIC to change
the location for one of the mics.
Cc: <stable@vger.kernel.org>
Signed-off-by: Hui Wang <hui.wang@canonical.com>
Link: https://lore.kernel.org/r/20200427030039.10121-1-hui.wang@canonical.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
sound/pci/hda/patch_realtek.c | 1 +
1 file changed, 1 insertion(+)
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -7295,6 +7295,7 @@ static const struct snd_pci_quirk alc269
SND_PCI_QUIRK(0x1558, 0x8560, "System76 Gazelle (gaze14)", ALC269_FIXUP_HEADSET_MIC),
SND_PCI_QUIRK(0x1558, 0x8561, "System76 Gazelle (gaze14)", ALC269_FIXUP_HEADSET_MIC),
SND_PCI_QUIRK(0x17aa, 0x1036, "Lenovo P520", ALC233_FIXUP_LENOVO_MULTI_CODECS),
+ SND_PCI_QUIRK(0x17aa, 0x1048, "ThinkCentre Station", ALC283_FIXUP_HEADSET_MIC),
SND_PCI_QUIRK(0x17aa, 0x20f2, "Thinkpad SL410/510", ALC269_FIXUP_SKU_IGNORE),
SND_PCI_QUIRK(0x17aa, 0x215e, "Thinkpad L512", ALC269_FIXUP_SKU_IGNORE),
SND_PCI_QUIRK(0x17aa, 0x21b8, "Thinkpad Edge 14", ALC269_FIXUP_SKU_IGNORE),
^ permalink raw reply [flat|nested] 62+ messages in thread* [PATCH 5.4 20/57] ALSA: usb-audio: Correct a typo of NuPrime DAC-10 USB ID
2020-05-04 17:57 [PATCH 5.4 00/57] 5.4.39-rc1 review Greg Kroah-Hartman
` (18 preceding siblings ...)
2020-05-04 17:57 ` [PATCH 5.4 19/57] ALSA: hda/realtek - Two front mics on a Lenovo ThinkCenter Greg Kroah-Hartman
@ 2020-05-04 17:57 ` Greg Kroah-Hartman
2020-05-04 17:57 ` [PATCH 5.4 21/57] ALSA: hda/hdmi: fix without unlocked before return Greg Kroah-Hartman
` (40 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: Greg Kroah-Hartman @ 2020-05-04 17:57 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Takashi Iwai
From: Takashi Iwai <tiwai@suse.de>
commit 547d2c9cf4f1f72adfecacbd5b093681fb0e8b3e upstream.
The USB vendor ID of NuPrime DAC-10 is not 16b0 but 16d0.
Fixes: f656891c6619 ("ALSA: usb-audio: add more quirks for DSD interfaces")
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200430124755.15940-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
sound/usb/quirks.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/sound/usb/quirks.c
+++ b/sound/usb/quirks.c
@@ -1643,7 +1643,7 @@ u64 snd_usb_interface_dsd_format_quirks(
case USB_ID(0x0d8c, 0x0316): /* Hegel HD12 DSD */
case USB_ID(0x10cb, 0x0103): /* The Bit Opus #3; with fp->dsd_raw */
- case USB_ID(0x16b0, 0x06b2): /* NuPrime DAC-10 */
+ case USB_ID(0x16d0, 0x06b2): /* NuPrime DAC-10 */
case USB_ID(0x16d0, 0x09dd): /* Encore mDSD */
case USB_ID(0x16d0, 0x0733): /* Furutech ADL Stratos */
case USB_ID(0x16d0, 0x09db): /* NuPrime Audio DAC-9 */
^ permalink raw reply [flat|nested] 62+ messages in thread* [PATCH 5.4 21/57] ALSA: hda/hdmi: fix without unlocked before return
2020-05-04 17:57 [PATCH 5.4 00/57] 5.4.39-rc1 review Greg Kroah-Hartman
` (19 preceding siblings ...)
2020-05-04 17:57 ` [PATCH 5.4 20/57] ALSA: usb-audio: Correct a typo of NuPrime DAC-10 USB ID Greg Kroah-Hartman
@ 2020-05-04 17:57 ` Greg Kroah-Hartman
2020-05-04 17:57 ` [PATCH 5.4 22/57] ALSA: line6: Fix POD HD500 audio playback Greg Kroah-Hartman
` (39 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: Greg Kroah-Hartman @ 2020-05-04 17:57 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Wu Bo, Takashi Iwai
From: Wu Bo <wubo40@huawei.com>
commit a2f647240998aa49632fb09b01388fdf2b87acfc upstream.
Fix the following coccicheck warning:
sound/pci/hda/patch_hdmi.c:1852:2-8: preceding lock on line 1846
After add sanity check to pass klockwork check,
The spdif_mutex should be unlock before return true
in check_non_pcm_per_cvt().
Fixes: 960a581e22d9 ("ALSA: hda: fix some klockwork scan warnings")
Signed-off-by: Wu Bo <wubo40@huawei.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/1587907042-694161-1-git-send-email-wubo40@huawei.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
sound/pci/hda/patch_hdmi.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/sound/pci/hda/patch_hdmi.c
+++ b/sound/pci/hda/patch_hdmi.c
@@ -1861,8 +1861,10 @@ static bool check_non_pcm_per_cvt(struct
/* Add sanity check to pass klockwork check.
* This should never happen.
*/
- if (WARN_ON(spdif == NULL))
+ if (WARN_ON(spdif == NULL)) {
+ mutex_unlock(&codec->spdif_mutex);
return true;
+ }
non_pcm = !!(spdif->status & IEC958_AES0_NONAUDIO);
mutex_unlock(&codec->spdif_mutex);
return non_pcm;
^ permalink raw reply [flat|nested] 62+ messages in thread* [PATCH 5.4 22/57] ALSA: line6: Fix POD HD500 audio playback
2020-05-04 17:57 [PATCH 5.4 00/57] 5.4.39-rc1 review Greg Kroah-Hartman
` (20 preceding siblings ...)
2020-05-04 17:57 ` [PATCH 5.4 21/57] ALSA: hda/hdmi: fix without unlocked before return Greg Kroah-Hartman
@ 2020-05-04 17:57 ` Greg Kroah-Hartman
2020-05-04 17:57 ` [PATCH 5.4 23/57] ALSA: pcm: oss: Place the plugin buffer overflow checks correctly Greg Kroah-Hartman
` (38 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: Greg Kroah-Hartman @ 2020-05-04 17:57 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Vasily Khoruzhick, Takashi Iwai
From: Vasily Khoruzhick <anarsoul@gmail.com>
commit cc18b2f4f3f1d7ed3125ac1840794f9feab0325c upstream.
Apparently interface 1 is control interface akin to HD500X,
setting LINE6_CAP_CONTROL and choosing it as ctrl_if fixes
audio playback on POD HD500.
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200425201115.3430-1-anarsoul@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
sound/usb/line6/podhd.c | 22 +++++-----------------
1 file changed, 5 insertions(+), 17 deletions(-)
--- a/sound/usb/line6/podhd.c
+++ b/sound/usb/line6/podhd.c
@@ -21,8 +21,7 @@
enum {
LINE6_PODHD300,
LINE6_PODHD400,
- LINE6_PODHD500_0,
- LINE6_PODHD500_1,
+ LINE6_PODHD500,
LINE6_PODX3,
LINE6_PODX3LIVE,
LINE6_PODHD500X,
@@ -318,8 +317,7 @@ static const struct usb_device_id podhd_
/* TODO: no need to alloc data interfaces when only audio is used */
{ LINE6_DEVICE(0x5057), .driver_info = LINE6_PODHD300 },
{ LINE6_DEVICE(0x5058), .driver_info = LINE6_PODHD400 },
- { LINE6_IF_NUM(0x414D, 0), .driver_info = LINE6_PODHD500_0 },
- { LINE6_IF_NUM(0x414D, 1), .driver_info = LINE6_PODHD500_1 },
+ { LINE6_IF_NUM(0x414D, 0), .driver_info = LINE6_PODHD500 },
{ LINE6_IF_NUM(0x414A, 0), .driver_info = LINE6_PODX3 },
{ LINE6_IF_NUM(0x414B, 0), .driver_info = LINE6_PODX3LIVE },
{ LINE6_IF_NUM(0x4159, 0), .driver_info = LINE6_PODHD500X },
@@ -352,23 +350,13 @@ static const struct line6_properties pod
.ep_audio_r = 0x82,
.ep_audio_w = 0x01,
},
- [LINE6_PODHD500_0] = {
+ [LINE6_PODHD500] = {
.id = "PODHD500",
.name = "POD HD500",
- .capabilities = LINE6_CAP_PCM
+ .capabilities = LINE6_CAP_PCM | LINE6_CAP_CONTROL
| LINE6_CAP_HWMON,
.altsetting = 1,
- .ep_ctrl_r = 0x81,
- .ep_ctrl_w = 0x01,
- .ep_audio_r = 0x86,
- .ep_audio_w = 0x02,
- },
- [LINE6_PODHD500_1] = {
- .id = "PODHD500",
- .name = "POD HD500",
- .capabilities = LINE6_CAP_PCM
- | LINE6_CAP_HWMON,
- .altsetting = 0,
+ .ctrl_if = 1,
.ep_ctrl_r = 0x81,
.ep_ctrl_w = 0x01,
.ep_audio_r = 0x86,
^ permalink raw reply [flat|nested] 62+ messages in thread* [PATCH 5.4 23/57] ALSA: pcm: oss: Place the plugin buffer overflow checks correctly
2020-05-04 17:57 [PATCH 5.4 00/57] 5.4.39-rc1 review Greg Kroah-Hartman
` (21 preceding siblings ...)
2020-05-04 17:57 ` [PATCH 5.4 22/57] ALSA: line6: Fix POD HD500 audio playback Greg Kroah-Hartman
@ 2020-05-04 17:57 ` Greg Kroah-Hartman
2020-05-04 17:57 ` [PATCH 5.4 24/57] i2c: amd-mp2-pci: Fix Oops in amd_mp2_pci_init() error handling Greg Kroah-Hartman
` (37 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: Greg Kroah-Hartman @ 2020-05-04 17:57 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Takashi Iwai
From: Takashi Iwai <tiwai@suse.de>
commit 4285de0725b1bf73608abbcd35ad7fd3ddc0b61e upstream.
The checks of the plugin buffer overflow in the previous fix by commit
f2ecf903ef06 ("ALSA: pcm: oss: Avoid plugin buffer overflow")
are put in the wrong places mistakenly, which leads to the expected
(repeated) sound when the rate plugin is involved. Fix in the right
places.
Also, at those right places, the zero check is needed for the
termination node, so added there as well, and let's get it done,
finally.
Fixes: f2ecf903ef06 ("ALSA: pcm: oss: Avoid plugin buffer overflow")
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200424193350.19678-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
sound/core/oss/pcm_plugin.c | 20 ++++++++++++--------
1 file changed, 12 insertions(+), 8 deletions(-)
--- a/sound/core/oss/pcm_plugin.c
+++ b/sound/core/oss/pcm_plugin.c
@@ -211,21 +211,23 @@ static snd_pcm_sframes_t plug_client_siz
if (stream == SNDRV_PCM_STREAM_PLAYBACK) {
plugin = snd_pcm_plug_last(plug);
while (plugin && drv_frames > 0) {
- if (check_size && drv_frames > plugin->buf_frames)
- drv_frames = plugin->buf_frames;
plugin_prev = plugin->prev;
if (plugin->src_frames)
drv_frames = plugin->src_frames(plugin, drv_frames);
+ if (check_size && plugin->buf_frames &&
+ drv_frames > plugin->buf_frames)
+ drv_frames = plugin->buf_frames;
plugin = plugin_prev;
}
} else if (stream == SNDRV_PCM_STREAM_CAPTURE) {
plugin = snd_pcm_plug_first(plug);
while (plugin && drv_frames > 0) {
plugin_next = plugin->next;
+ if (check_size && plugin->buf_frames &&
+ drv_frames > plugin->buf_frames)
+ drv_frames = plugin->buf_frames;
if (plugin->dst_frames)
drv_frames = plugin->dst_frames(plugin, drv_frames);
- if (check_size && drv_frames > plugin->buf_frames)
- drv_frames = plugin->buf_frames;
plugin = plugin_next;
}
} else
@@ -251,26 +253,28 @@ static snd_pcm_sframes_t plug_slave_size
plugin = snd_pcm_plug_first(plug);
while (plugin && frames > 0) {
plugin_next = plugin->next;
+ if (check_size && plugin->buf_frames &&
+ frames > plugin->buf_frames)
+ frames = plugin->buf_frames;
if (plugin->dst_frames) {
frames = plugin->dst_frames(plugin, frames);
if (frames < 0)
return frames;
}
- if (check_size && frames > plugin->buf_frames)
- frames = plugin->buf_frames;
plugin = plugin_next;
}
} else if (stream == SNDRV_PCM_STREAM_CAPTURE) {
plugin = snd_pcm_plug_last(plug);
while (plugin) {
- if (check_size && frames > plugin->buf_frames)
- frames = plugin->buf_frames;
plugin_prev = plugin->prev;
if (plugin->src_frames) {
frames = plugin->src_frames(plugin, frames);
if (frames < 0)
return frames;
}
+ if (check_size && plugin->buf_frames &&
+ frames > plugin->buf_frames)
+ frames = plugin->buf_frames;
plugin = plugin_prev;
}
} else
^ permalink raw reply [flat|nested] 62+ messages in thread* [PATCH 5.4 24/57] i2c: amd-mp2-pci: Fix Oops in amd_mp2_pci_init() error handling
2020-05-04 17:57 [PATCH 5.4 00/57] 5.4.39-rc1 review Greg Kroah-Hartman
` (22 preceding siblings ...)
2020-05-04 17:57 ` [PATCH 5.4 23/57] ALSA: pcm: oss: Place the plugin buffer overflow checks correctly Greg Kroah-Hartman
@ 2020-05-04 17:57 ` Greg Kroah-Hartman
2020-05-04 17:57 ` [PATCH 5.4 25/57] Drivers: hv: vmbus: Fix Suspend-to-Idle for Generation-2 VM Greg Kroah-Hartman
` (36 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: Greg Kroah-Hartman @ 2020-05-04 17:57 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Dan Carpenter, Wolfram Sang, stable
From: Dan Carpenter <dan.carpenter@oracle.com>
commit ac2b0813fceaf7cb3d8d46c7b33c90bae9fa49db upstream.
The problem is that we dereference "privdata->pci_dev" when we print
the error messages in amd_mp2_pci_init():
dev_err(ndev_dev(privdata), "Failed to enable MP2 PCI device\n");
^^^^^^^^^^^^^^^^^
Fixes: 529766e0a011 ("i2c: Add drivers for the AMD PCIe MP2 I2C controller")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Cc: stable@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/i2c/busses/i2c-amd-mp2-pci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/i2c/busses/i2c-amd-mp2-pci.c
+++ b/drivers/i2c/busses/i2c-amd-mp2-pci.c
@@ -349,12 +349,12 @@ static int amd_mp2_pci_probe(struct pci_
if (!privdata)
return -ENOMEM;
+ privdata->pci_dev = pci_dev;
rc = amd_mp2_pci_init(privdata, pci_dev);
if (rc)
return rc;
mutex_init(&privdata->c2p_lock);
- privdata->pci_dev = pci_dev;
pm_runtime_set_autosuspend_delay(&pci_dev->dev, 1000);
pm_runtime_use_autosuspend(&pci_dev->dev);
^ permalink raw reply [flat|nested] 62+ messages in thread* [PATCH 5.4 25/57] Drivers: hv: vmbus: Fix Suspend-to-Idle for Generation-2 VM
2020-05-04 17:57 [PATCH 5.4 00/57] 5.4.39-rc1 review Greg Kroah-Hartman
` (23 preceding siblings ...)
2020-05-04 17:57 ` [PATCH 5.4 24/57] i2c: amd-mp2-pci: Fix Oops in amd_mp2_pci_init() error handling Greg Kroah-Hartman
@ 2020-05-04 17:57 ` Greg Kroah-Hartman
2020-05-04 17:57 ` [PATCH 5.4 26/57] dlmfs_file_write(): fix the bogosity in handling non-zero *ppos Greg Kroah-Hartman
` (35 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: Greg Kroah-Hartman @ 2020-05-04 17:57 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Michael Kelley, Dexuan Cui, Wei Liu
From: Dexuan Cui <decui@microsoft.com>
commit 1a06d017fb3f388734ffbe5dedee6f8c3af5f2db upstream.
Before the hibernation patchset (e.g. f53335e3289f), in a Generation-2
Linux VM on Hyper-V, the user can run "echo freeze > /sys/power/state" to
freeze the system, i.e. Suspend-to-Idle. The user can press the keyboard
or move the mouse to wake up the VM.
With the hibernation patchset, Linux VM on Hyper-V can hibernate to disk,
but Suspend-to-Idle is broken: when the synthetic keyboard/mouse are
suspended, there is no way to wake up the VM.
Fix the issue by not suspending and resuming the vmbus devices upon
Suspend-to-Idle.
Fixes: f53335e3289f ("Drivers: hv: vmbus: Suspend/resume the vmbus itself for hibernation")
Cc: stable@vger.kernel.org
Reviewed-by: Michael Kelley <mikelley@microsoft.com>
Signed-off-by: Dexuan Cui <decui@microsoft.com>
Link: https://lore.kernel.org/r/1586663435-36243-1-git-send-email-decui@microsoft.com
Signed-off-by: Wei Liu <wei.liu@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/hv/vmbus_drv.c | 43 ++++++++++++++++++++++++++++++++++---------
1 file changed, 34 insertions(+), 9 deletions(-)
--- a/drivers/hv/vmbus_drv.c
+++ b/drivers/hv/vmbus_drv.c
@@ -978,6 +978,9 @@ static int vmbus_resume(struct device *c
return drv->resume(dev);
}
+#else
+#define vmbus_suspend NULL
+#define vmbus_resume NULL
#endif /* CONFIG_PM_SLEEP */
/*
@@ -995,11 +998,22 @@ static void vmbus_device_release(struct
}
/*
- * Note: we must use SET_NOIRQ_SYSTEM_SLEEP_PM_OPS rather than
- * SET_SYSTEM_SLEEP_PM_OPS: see the comment before vmbus_bus_pm.
+ * Note: we must use the "noirq" ops: see the comment before vmbus_bus_pm.
+ *
+ * suspend_noirq/resume_noirq are set to NULL to support Suspend-to-Idle: we
+ * shouldn't suspend the vmbus devices upon Suspend-to-Idle, otherwise there
+ * is no way to wake up a Generation-2 VM.
+ *
+ * The other 4 ops are for hibernation.
*/
+
static const struct dev_pm_ops vmbus_pm = {
- SET_NOIRQ_SYSTEM_SLEEP_PM_OPS(vmbus_suspend, vmbus_resume)
+ .suspend_noirq = NULL,
+ .resume_noirq = NULL,
+ .freeze_noirq = vmbus_suspend,
+ .thaw_noirq = vmbus_resume,
+ .poweroff_noirq = vmbus_suspend,
+ .restore_noirq = vmbus_resume,
};
/* The one and only one */
@@ -2280,6 +2294,9 @@ static int vmbus_bus_resume(struct devic
return 0;
}
+#else
+#define vmbus_bus_suspend NULL
+#define vmbus_bus_resume NULL
#endif /* CONFIG_PM_SLEEP */
static const struct acpi_device_id vmbus_acpi_device_ids[] = {
@@ -2290,16 +2307,24 @@ static const struct acpi_device_id vmbus
MODULE_DEVICE_TABLE(acpi, vmbus_acpi_device_ids);
/*
- * Note: we must use SET_NOIRQ_SYSTEM_SLEEP_PM_OPS rather than
- * SET_SYSTEM_SLEEP_PM_OPS, otherwise NIC SR-IOV can not work, because the
- * "pci_dev_pm_ops" uses the "noirq" callbacks: in the resume path, the
- * pci "noirq" restore callback runs before "non-noirq" callbacks (see
+ * Note: we must use the "no_irq" ops, otherwise hibernation can not work with
+ * PCI device assignment, because "pci_dev_pm_ops" uses the "noirq" ops: in
+ * the resume path, the pci "noirq" restore op runs before "non-noirq" op (see
* resume_target_kernel() -> dpm_resume_start(), and hibernation_restore() ->
* dpm_resume_end()). This means vmbus_bus_resume() and the pci-hyperv's
- * resume callback must also run via the "noirq" callbacks.
+ * resume callback must also run via the "noirq" ops.
+ *
+ * Set suspend_noirq/resume_noirq to NULL for Suspend-to-Idle: see the comment
+ * earlier in this file before vmbus_pm.
*/
+
static const struct dev_pm_ops vmbus_bus_pm = {
- SET_NOIRQ_SYSTEM_SLEEP_PM_OPS(vmbus_bus_suspend, vmbus_bus_resume)
+ .suspend_noirq = NULL,
+ .resume_noirq = NULL,
+ .freeze_noirq = vmbus_bus_suspend,
+ .thaw_noirq = vmbus_bus_resume,
+ .poweroff_noirq = vmbus_bus_suspend,
+ .restore_noirq = vmbus_bus_resume
};
static struct acpi_driver vmbus_acpi_driver = {
^ permalink raw reply [flat|nested] 62+ messages in thread* [PATCH 5.4 26/57] dlmfs_file_write(): fix the bogosity in handling non-zero *ppos
2020-05-04 17:57 [PATCH 5.4 00/57] 5.4.39-rc1 review Greg Kroah-Hartman
` (24 preceding siblings ...)
2020-05-04 17:57 ` [PATCH 5.4 25/57] Drivers: hv: vmbus: Fix Suspend-to-Idle for Generation-2 VM Greg Kroah-Hartman
@ 2020-05-04 17:57 ` Greg Kroah-Hartman
2020-05-04 17:57 ` [PATCH 5.4 27/57] IB/rdmavt: Always return ERR_PTR from rvt_create_mmap_info() Greg Kroah-Hartman
` (34 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: Greg Kroah-Hartman @ 2020-05-04 17:57 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Al Viro
From: Al Viro <viro@zeniv.linux.org.uk>
commit 3815f1be546e752327b5868af103ccdddcc4db77 upstream.
'count' is how much you want written, not the final position.
Moreover, it can legitimately be less than the current position...
Cc: stable@vger.kernel.org
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/ocfs2/dlmfs/dlmfs.c | 27 ++++++++++++---------------
1 file changed, 12 insertions(+), 15 deletions(-)
--- a/fs/ocfs2/dlmfs/dlmfs.c
+++ b/fs/ocfs2/dlmfs/dlmfs.c
@@ -275,7 +275,6 @@ static ssize_t dlmfs_file_write(struct f
loff_t *ppos)
{
int bytes_left;
- ssize_t writelen;
char *lvb_buf;
struct inode *inode = file_inode(filp);
@@ -285,32 +284,30 @@ static ssize_t dlmfs_file_write(struct f
if (*ppos >= i_size_read(inode))
return -ENOSPC;
+ /* don't write past the lvb */
+ if (count > i_size_read(inode) - *ppos)
+ count = i_size_read(inode) - *ppos;
+
if (!count)
return 0;
if (!access_ok(buf, count))
return -EFAULT;
- /* don't write past the lvb */
- if ((count + *ppos) > i_size_read(inode))
- writelen = i_size_read(inode) - *ppos;
- else
- writelen = count - *ppos;
-
- lvb_buf = kmalloc(writelen, GFP_NOFS);
+ lvb_buf = kmalloc(count, GFP_NOFS);
if (!lvb_buf)
return -ENOMEM;
- bytes_left = copy_from_user(lvb_buf, buf, writelen);
- writelen -= bytes_left;
- if (writelen)
- user_dlm_write_lvb(inode, lvb_buf, writelen);
+ bytes_left = copy_from_user(lvb_buf, buf, count);
+ count -= bytes_left;
+ if (count)
+ user_dlm_write_lvb(inode, lvb_buf, count);
kfree(lvb_buf);
- *ppos = *ppos + writelen;
- mlog(0, "wrote %zd bytes\n", writelen);
- return writelen;
+ *ppos = *ppos + count;
+ mlog(0, "wrote %zu bytes\n", count);
+ return count;
}
static void dlmfs_init_once(void *foo)
^ permalink raw reply [flat|nested] 62+ messages in thread* [PATCH 5.4 27/57] IB/rdmavt: Always return ERR_PTR from rvt_create_mmap_info()
2020-05-04 17:57 [PATCH 5.4 00/57] 5.4.39-rc1 review Greg Kroah-Hartman
` (25 preceding siblings ...)
2020-05-04 17:57 ` [PATCH 5.4 26/57] dlmfs_file_write(): fix the bogosity in handling non-zero *ppos Greg Kroah-Hartman
@ 2020-05-04 17:57 ` Greg Kroah-Hartman
2020-05-04 17:57 ` [PATCH 5.4 28/57] PM: ACPI: Output correct message on target power state Greg Kroah-Hartman
` (33 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: Greg Kroah-Hartman @ 2020-05-04 17:57 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Mike Marciniszyn, Sudip Mukherjee,
Jason Gunthorpe
From: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
commit 47c370c1a5eea9b2f6f026d49e060c3748c89667 upstream.
The commit below modified rvt_create_mmap_info() to return ERR_PTR's but
didn't update the callers to handle them. Modify rvt_create_mmap_info() to
only return ERR_PTR and fix all error checking after
rvt_create_mmap_info() was called.
Fixes: ff23dfa13457 ("IB: Pass only ib_udata in function prototypes")
Link: https://lore.kernel.org/r/20200424173146.10970-1-sudipm.mukherjee@gmail.com
Cc: stable@vger.kernel.org [5.4+]
Tested-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
Acked-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
Signed-off-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/infiniband/sw/rdmavt/cq.c | 4 ++--
drivers/infiniband/sw/rdmavt/mmap.c | 4 ++--
drivers/infiniband/sw/rdmavt/qp.c | 4 ++--
drivers/infiniband/sw/rdmavt/srq.c | 4 ++--
4 files changed, 8 insertions(+), 8 deletions(-)
--- a/drivers/infiniband/sw/rdmavt/cq.c
+++ b/drivers/infiniband/sw/rdmavt/cq.c
@@ -248,8 +248,8 @@ int rvt_create_cq(struct ib_cq *ibcq, co
*/
if (udata && udata->outlen >= sizeof(__u64)) {
cq->ip = rvt_create_mmap_info(rdi, sz, udata, u_wc);
- if (!cq->ip) {
- err = -ENOMEM;
+ if (IS_ERR(cq->ip)) {
+ err = PTR_ERR(cq->ip);
goto bail_wc;
}
--- a/drivers/infiniband/sw/rdmavt/mmap.c
+++ b/drivers/infiniband/sw/rdmavt/mmap.c
@@ -154,7 +154,7 @@ done:
* @udata: user data (must be valid!)
* @obj: opaque pointer to a cq, wq etc
*
- * Return: rvt_mmap struct on success
+ * Return: rvt_mmap struct on success, ERR_PTR on failure
*/
struct rvt_mmap_info *rvt_create_mmap_info(struct rvt_dev_info *rdi, u32 size,
struct ib_udata *udata, void *obj)
@@ -166,7 +166,7 @@ struct rvt_mmap_info *rvt_create_mmap_in
ip = kmalloc_node(sizeof(*ip), GFP_KERNEL, rdi->dparms.node);
if (!ip)
- return ip;
+ return ERR_PTR(-ENOMEM);
size = PAGE_ALIGN(size);
--- a/drivers/infiniband/sw/rdmavt/qp.c
+++ b/drivers/infiniband/sw/rdmavt/qp.c
@@ -1244,8 +1244,8 @@ struct ib_qp *rvt_create_qp(struct ib_pd
qp->ip = rvt_create_mmap_info(rdi, s, udata,
qp->r_rq.wq);
- if (!qp->ip) {
- ret = ERR_PTR(-ENOMEM);
+ if (IS_ERR(qp->ip)) {
+ ret = ERR_CAST(qp->ip);
goto bail_qpn;
}
--- a/drivers/infiniband/sw/rdmavt/srq.c
+++ b/drivers/infiniband/sw/rdmavt/srq.c
@@ -111,8 +111,8 @@ int rvt_create_srq(struct ib_srq *ibsrq,
u32 s = sizeof(struct rvt_rwq) + srq->rq.size * sz;
srq->ip = rvt_create_mmap_info(dev, s, udata, srq->rq.wq);
- if (!srq->ip) {
- ret = -ENOMEM;
+ if (IS_ERR(srq->ip)) {
+ ret = PTR_ERR(srq->ip);
goto bail_wq;
}
^ permalink raw reply [flat|nested] 62+ messages in thread* [PATCH 5.4 28/57] PM: ACPI: Output correct message on target power state
2020-05-04 17:57 [PATCH 5.4 00/57] 5.4.39-rc1 review Greg Kroah-Hartman
` (26 preceding siblings ...)
2020-05-04 17:57 ` [PATCH 5.4 27/57] IB/rdmavt: Always return ERR_PTR from rvt_create_mmap_info() Greg Kroah-Hartman
@ 2020-05-04 17:57 ` Greg Kroah-Hartman
2020-05-04 17:57 ` [PATCH 5.4 29/57] PM: hibernate: Freeze kernel threads in software_resume() Greg Kroah-Hartman
` (32 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: Greg Kroah-Hartman @ 2020-05-04 17:57 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Kai-Heng Feng, Rafael J. Wysocki
From: Kai-Heng Feng <kai.heng.feng@canonical.com>
commit a9b760b0266f563b4784f695bbd0e717610dc10a upstream.
Transitioned power state logged at the end of setting ACPI power.
However, D3cold won't be in the message because state can only be
D3hot at most.
Use target_state to corretly report when power state is D3cold.
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/acpi/device_pm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/acpi/device_pm.c
+++ b/drivers/acpi/device_pm.c
@@ -273,13 +273,13 @@ int acpi_device_set_power(struct acpi_de
end:
if (result) {
dev_warn(&device->dev, "Failed to change power state to %s\n",
- acpi_power_state_string(state));
+ acpi_power_state_string(target_state));
} else {
device->power.state = target_state;
ACPI_DEBUG_PRINT((ACPI_DB_INFO,
"Device [%s] transitioned to %s\n",
device->pnp.bus_id,
- acpi_power_state_string(state)));
+ acpi_power_state_string(target_state)));
}
return result;
^ permalink raw reply [flat|nested] 62+ messages in thread* [PATCH 5.4 29/57] PM: hibernate: Freeze kernel threads in software_resume()
2020-05-04 17:57 [PATCH 5.4 00/57] 5.4.39-rc1 review Greg Kroah-Hartman
` (27 preceding siblings ...)
2020-05-04 17:57 ` [PATCH 5.4 28/57] PM: ACPI: Output correct message on target power state Greg Kroah-Hartman
@ 2020-05-04 17:57 ` Greg Kroah-Hartman
2020-05-04 17:57 ` [PATCH 5.4 30/57] dm verity fec: fix hash block number in verity_fec_decode Greg Kroah-Hartman
` (31 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: Greg Kroah-Hartman @ 2020-05-04 17:57 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Dexuan Cui, Rafael J. Wysocki
From: Dexuan Cui <decui@microsoft.com>
commit 2351f8d295ed63393190e39c2f7c1fee1a80578f upstream.
Currently the kernel threads are not frozen in software_resume(), so
between dpm_suspend_start(PMSG_QUIESCE) and resume_target_kernel(),
system_freezable_power_efficient_wq can still try to submit SCSI
commands and this can cause a panic since the low level SCSI driver
(e.g. hv_storvsc) has quiesced the SCSI adapter and can not accept
any SCSI commands: https://lkml.org/lkml/2020/4/10/47
At first I posted a fix (https://lkml.org/lkml/2020/4/21/1318) trying
to resolve the issue from hv_storvsc, but with the help of
Bart Van Assche, I realized it's better to fix software_resume(),
since this looks like a generic issue, not only pertaining to SCSI.
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: Dexuan Cui <decui@microsoft.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
kernel/power/hibernate.c | 7 +++++++
1 file changed, 7 insertions(+)
--- a/kernel/power/hibernate.c
+++ b/kernel/power/hibernate.c
@@ -898,6 +898,13 @@ static int software_resume(void)
error = freeze_processes();
if (error)
goto Close_Finish;
+
+ error = freeze_kernel_threads();
+ if (error) {
+ thaw_processes();
+ goto Close_Finish;
+ }
+
error = load_image_and_restore();
thaw_processes();
Finish:
^ permalink raw reply [flat|nested] 62+ messages in thread* [PATCH 5.4 30/57] dm verity fec: fix hash block number in verity_fec_decode
2020-05-04 17:57 [PATCH 5.4 00/57] 5.4.39-rc1 review Greg Kroah-Hartman
` (28 preceding siblings ...)
2020-05-04 17:57 ` [PATCH 5.4 29/57] PM: hibernate: Freeze kernel threads in software_resume() Greg Kroah-Hartman
@ 2020-05-04 17:57 ` Greg Kroah-Hartman
2020-05-04 17:57 ` [PATCH 5.4 31/57] dm writecache: fix data corruption when reloading the target Greg Kroah-Hartman
` (30 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: Greg Kroah-Hartman @ 2020-05-04 17:57 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Sunwook Eom, Sami Tolvanen, Mike Snitzer
From: Sunwook Eom <speed.eom@samsung.com>
commit ad4e80a639fc61d5ecebb03caa5cdbfb91fcebfc upstream.
The error correction data is computed as if data and hash blocks
were concatenated. But hash block number starts from v->hash_start.
So, we have to calculate hash block number based on that.
Fixes: a739ff3f543af ("dm verity: add support for forward error correction")
Cc: stable@vger.kernel.org
Signed-off-by: Sunwook Eom <speed.eom@samsung.com>
Reviewed-by: Sami Tolvanen <samitolvanen@google.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/md/dm-verity-fec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/md/dm-verity-fec.c
+++ b/drivers/md/dm-verity-fec.c
@@ -435,7 +435,7 @@ int verity_fec_decode(struct dm_verity *
fio->level++;
if (type == DM_VERITY_BLOCK_TYPE_METADATA)
- block += v->data_blocks;
+ block = block - v->hash_start + v->data_blocks;
/*
* For RS(M, N), the continuous FEC data is divided into blocks of N
^ permalink raw reply [flat|nested] 62+ messages in thread* [PATCH 5.4 31/57] dm writecache: fix data corruption when reloading the target
2020-05-04 17:57 [PATCH 5.4 00/57] 5.4.39-rc1 review Greg Kroah-Hartman
` (29 preceding siblings ...)
2020-05-04 17:57 ` [PATCH 5.4 30/57] dm verity fec: fix hash block number in verity_fec_decode Greg Kroah-Hartman
@ 2020-05-04 17:57 ` Greg Kroah-Hartman
2020-05-04 17:57 ` [PATCH 5.4 32/57] dm multipath: use updated MPATHF_QUEUE_IO on mapping for bio-based mpath Greg Kroah-Hartman
` (29 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: Greg Kroah-Hartman @ 2020-05-04 17:57 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Mikulas Patocka, Mike Snitzer
From: Mikulas Patocka <mpatocka@redhat.com>
commit 31b22120194b5c0d460f59e0c98504de1d3f1f14 upstream.
The dm-writecache reads metadata in the target constructor. However, when
we reload the target, there could be another active instance running on
the same device. This is the sequence of operations when doing a reload:
1. construct new target
2. suspend old target
3. resume new target
4. destroy old target
Metadata that were written by the old target between steps 1 and 2 would
not be visible by the new target.
Fix the data corruption by loading the metadata in the resume handler.
Also, validate block_size is at least as large as both the devices'
logical block size and only read 1 block from the metadata during
target constructor -- no need to read entirety of metadata now that it
is done during resume.
Fixes: 48debafe4f2f ("dm: add writecache target")
Cc: stable@vger.kernel.org # v4.18+
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/md/dm-writecache.c | 52 ++++++++++++++++++++++++++++++++-------------
1 file changed, 37 insertions(+), 15 deletions(-)
--- a/drivers/md/dm-writecache.c
+++ b/drivers/md/dm-writecache.c
@@ -878,6 +878,24 @@ static int writecache_alloc_entries(stru
return 0;
}
+static int writecache_read_metadata(struct dm_writecache *wc, sector_t n_sectors)
+{
+ struct dm_io_region region;
+ struct dm_io_request req;
+
+ region.bdev = wc->ssd_dev->bdev;
+ region.sector = wc->start_sector;
+ region.count = n_sectors;
+ req.bi_op = REQ_OP_READ;
+ req.bi_op_flags = REQ_SYNC;
+ req.mem.type = DM_IO_VMA;
+ req.mem.ptr.vma = (char *)wc->memory_map;
+ req.client = wc->dm_io;
+ req.notify.fn = NULL;
+
+ return dm_io(&req, 1, ®ion, NULL);
+}
+
static void writecache_resume(struct dm_target *ti)
{
struct dm_writecache *wc = ti->private;
@@ -888,8 +906,18 @@ static void writecache_resume(struct dm_
wc_lock(wc);
- if (WC_MODE_PMEM(wc))
+ if (WC_MODE_PMEM(wc)) {
persistent_memory_invalidate_cache(wc->memory_map, wc->memory_map_size);
+ } else {
+ r = writecache_read_metadata(wc, wc->metadata_sectors);
+ if (r) {
+ size_t sb_entries_offset;
+ writecache_error(wc, r, "unable to read metadata: %d", r);
+ sb_entries_offset = offsetof(struct wc_memory_superblock, entries);
+ memset((char *)wc->memory_map + sb_entries_offset, -1,
+ (wc->metadata_sectors << SECTOR_SHIFT) - sb_entries_offset);
+ }
+ }
wc->tree = RB_ROOT;
INIT_LIST_HEAD(&wc->lru);
@@ -1984,6 +2012,12 @@ static int writecache_ctr(struct dm_targ
ti->error = "Invalid block size";
goto bad;
}
+ if (wc->block_size < bdev_logical_block_size(wc->dev->bdev) ||
+ wc->block_size < bdev_logical_block_size(wc->ssd_dev->bdev)) {
+ r = -EINVAL;
+ ti->error = "Block size is smaller than device logical block size";
+ goto bad;
+ }
wc->block_size_bits = __ffs(wc->block_size);
wc->max_writeback_jobs = MAX_WRITEBACK_JOBS;
@@ -2072,8 +2106,6 @@ invalid_optional:
goto bad;
}
} else {
- struct dm_io_region region;
- struct dm_io_request req;
size_t n_blocks, n_metadata_blocks;
uint64_t n_bitmap_bits;
@@ -2130,19 +2162,9 @@ invalid_optional:
goto bad;
}
- region.bdev = wc->ssd_dev->bdev;
- region.sector = wc->start_sector;
- region.count = wc->metadata_sectors;
- req.bi_op = REQ_OP_READ;
- req.bi_op_flags = REQ_SYNC;
- req.mem.type = DM_IO_VMA;
- req.mem.ptr.vma = (char *)wc->memory_map;
- req.client = wc->dm_io;
- req.notify.fn = NULL;
-
- r = dm_io(&req, 1, ®ion, NULL);
+ r = writecache_read_metadata(wc, wc->block_size >> SECTOR_SHIFT);
if (r) {
- ti->error = "Unable to read metadata";
+ ti->error = "Unable to read first block of metadata";
goto bad;
}
}
^ permalink raw reply [flat|nested] 62+ messages in thread* [PATCH 5.4 32/57] dm multipath: use updated MPATHF_QUEUE_IO on mapping for bio-based mpath
2020-05-04 17:57 [PATCH 5.4 00/57] 5.4.39-rc1 review Greg Kroah-Hartman
` (30 preceding siblings ...)
2020-05-04 17:57 ` [PATCH 5.4 31/57] dm writecache: fix data corruption when reloading the target Greg Kroah-Hartman
@ 2020-05-04 17:57 ` Greg Kroah-Hartman
2020-05-04 17:57 ` [PATCH 5.4 33/57] ARM: dts: imx6qdl-sr-som-ti: indicate powering off wifi is safe Greg Kroah-Hartman
` (28 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: Greg Kroah-Hartman @ 2020-05-04 17:57 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Gabriel Krisman Bertazi, Mike Snitzer
From: Gabriel Krisman Bertazi <krisman@collabora.com>
commit 5686dee34dbfe0238c0274e0454fa0174ac0a57a upstream.
When adding devices that don't have a scsi_dh on a BIO based multipath,
I was able to consistently hit the warning below and lock-up the system.
The problem is that __map_bio reads the flag before it potentially being
modified by choose_pgpath, and ends up using the older value.
The WARN_ON below is not trivially linked to the issue. It goes like
this: The activate_path delayed_work is not initialized for non-scsi_dh
devices, but we always set MPATHF_QUEUE_IO, asking for initialization.
That is fine, since MPATHF_QUEUE_IO would be cleared in choose_pgpath.
Nevertheless, only for BIO-based mpath, we cache the flag before calling
choose_pgpath, and use the older version when deciding if we should
initialize the path. Therefore, we end up trying to initialize the
paths, and calling the non-initialized activate_path work.
[ 82.437100] ------------[ cut here ]------------
[ 82.437659] WARNING: CPU: 3 PID: 602 at kernel/workqueue.c:1624
__queue_delayed_work+0x71/0x90
[ 82.438436] Modules linked in:
[ 82.438911] CPU: 3 PID: 602 Comm: systemd-udevd Not tainted 5.6.0-rc6+ #339
[ 82.439680] RIP: 0010:__queue_delayed_work+0x71/0x90
[ 82.440287] Code: c1 48 89 4a 50 81 ff 00 02 00 00 75 2a 4c 89 cf e9
94 d6 07 00 e9 7f e9 ff ff 0f 0b eb c7 0f 0b 48 81 7a 58 40 74 a8 94 74
a7 <0f> 0b 48 83 7a 48 00 74 a5 0f 0b eb a1 89 fe 4c 89 cf e9 c8 c4 07
[ 82.441719] RSP: 0018:ffffb738803977c0 EFLAGS: 00010007
[ 82.442121] RAX: ffffa086389f9740 RBX: 0000000000000002 RCX: 0000000000000000
[ 82.442718] RDX: ffffa086350dd930 RSI: ffffa0863d76f600 RDI: 0000000000000200
[ 82.443484] RBP: 0000000000000200 R08: 0000000000000000 R09: ffffa086350dd970
[ 82.444128] R10: 0000000000000000 R11: 0000000000000000 R12: ffffa086350dd930
[ 82.444773] R13: ffffa0863d76f600 R14: 0000000000000000 R15: ffffa08636738008
[ 82.445427] FS: 00007f6abfe9dd40(0000) GS:ffffa0863dd80000(0000) knlGS:00000
[ 82.446040] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 82.446478] CR2: 0000557d288db4e8 CR3: 0000000078b36000 CR4: 00000000000006e0
[ 82.447104] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 82.447561] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 82.448012] Call Trace:
[ 82.448164] queue_delayed_work_on+0x6d/0x80
[ 82.448472] __pg_init_all_paths+0x7b/0xf0
[ 82.448714] pg_init_all_paths+0x26/0x40
[ 82.448980] __multipath_map_bio.isra.0+0x84/0x210
[ 82.449267] __map_bio+0x3c/0x1f0
[ 82.449468] __split_and_process_non_flush+0x14a/0x1b0
[ 82.449775] __split_and_process_bio+0xde/0x340
[ 82.450045] ? dm_get_live_table+0x5/0xb0
[ 82.450278] dm_process_bio+0x98/0x290
[ 82.450518] dm_make_request+0x54/0x120
[ 82.450778] generic_make_request+0xd2/0x3e0
[ 82.451038] ? submit_bio+0x3c/0x150
[ 82.451278] submit_bio+0x3c/0x150
[ 82.451492] mpage_readpages+0x129/0x160
[ 82.451756] ? bdev_evict_inode+0x1d0/0x1d0
[ 82.452033] read_pages+0x72/0x170
[ 82.452260] __do_page_cache_readahead+0x1ba/0x1d0
[ 82.452624] force_page_cache_readahead+0x96/0x110
[ 82.452903] generic_file_read_iter+0x84f/0xae0
[ 82.453192] ? __seccomp_filter+0x7c/0x670
[ 82.453547] new_sync_read+0x10e/0x190
[ 82.453883] vfs_read+0x9d/0x150
[ 82.454172] ksys_read+0x65/0xe0
[ 82.454466] do_syscall_64+0x4e/0x210
[ 82.454828] entry_SYSCALL_64_after_hwframe+0x49/0xbe
[...]
[ 82.462501] ---[ end trace bb39975e9cf45daa ]---
Cc: stable@vger.kernel.org
Signed-off-by: Gabriel Krisman Bertazi <krisman@collabora.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/md/dm-mpath.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/drivers/md/dm-mpath.c
+++ b/drivers/md/dm-mpath.c
@@ -576,10 +576,12 @@ static struct pgpath *__map_bio(struct m
/* Do we need to select a new pgpath? */
pgpath = READ_ONCE(m->current_pgpath);
- queue_io = test_bit(MPATHF_QUEUE_IO, &m->flags);
- if (!pgpath || !queue_io)
+ if (!pgpath || !test_bit(MPATHF_QUEUE_IO, &m->flags))
pgpath = choose_pgpath(m, bio->bi_iter.bi_size);
+ /* MPATHF_QUEUE_IO might have been cleared by choose_pgpath. */
+ queue_io = test_bit(MPATHF_QUEUE_IO, &m->flags);
+
if ((pgpath && queue_io) ||
(!pgpath && test_bit(MPATHF_QUEUE_IF_NO_PATH, &m->flags))) {
/* Queue for the daemon to resubmit */
^ permalink raw reply [flat|nested] 62+ messages in thread* [PATCH 5.4 33/57] ARM: dts: imx6qdl-sr-som-ti: indicate powering off wifi is safe
2020-05-04 17:57 [PATCH 5.4 00/57] 5.4.39-rc1 review Greg Kroah-Hartman
` (31 preceding siblings ...)
2020-05-04 17:57 ` [PATCH 5.4 32/57] dm multipath: use updated MPATHF_QUEUE_IO on mapping for bio-based mpath Greg Kroah-Hartman
@ 2020-05-04 17:57 ` Greg Kroah-Hartman
2020-05-04 17:57 ` [PATCH 5.4 34/57] scsi: qla2xxx: set UNLOADING before waiting for session deletion Greg Kroah-Hartman
` (27 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: Greg Kroah-Hartman @ 2020-05-04 17:57 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Russell King, Fabio Estevam,
Shawn Guo, Miguel Borges de Freitas
From: Russell King <rmk+kernel@armlinux.org.uk>
commit b7dc7205b2ae6b6c9d9cfc3e47d6f08da8647b10 upstream.
We need to indicate that powering off the TI WiFi is safe, to avoid:
wl18xx_driver wl18xx.2.auto: Unbalanced pm_runtime_enable!
wl1271_sdio mmc0:0001:2: wl12xx_sdio_power_on: failed to get_sync(-13)
which prevents the WiFi being functional.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Reviewed-by: Fabio Estevam <festevam@gmail.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Cc: Miguel Borges de Freitas <miguelborgesdefreitas@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm/boot/dts/imx6qdl-sr-som-ti.dtsi | 1 +
1 file changed, 1 insertion(+)
--- a/arch/arm/boot/dts/imx6qdl-sr-som-ti.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-sr-som-ti.dtsi
@@ -153,6 +153,7 @@
bus-width = <4>;
keep-power-in-suspend;
mmc-pwrseq = <&pwrseq_ti_wifi>;
+ cap-power-off-card;
non-removable;
vmmc-supply = <&vcc_3v3>;
/* vqmmc-supply = <&nvcc_sd1>; - MMC layer doesn't like it! */
^ permalink raw reply [flat|nested] 62+ messages in thread* [PATCH 5.4 34/57] scsi: qla2xxx: set UNLOADING before waiting for session deletion
2020-05-04 17:57 [PATCH 5.4 00/57] 5.4.39-rc1 review Greg Kroah-Hartman
` (32 preceding siblings ...)
2020-05-04 17:57 ` [PATCH 5.4 33/57] ARM: dts: imx6qdl-sr-som-ti: indicate powering off wifi is safe Greg Kroah-Hartman
@ 2020-05-04 17:57 ` Greg Kroah-Hartman
2020-05-04 17:57 ` [PATCH 5.4 35/57] scsi: qla2xxx: check UNLOADING before posting async work Greg Kroah-Hartman
` (26 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: Greg Kroah-Hartman @ 2020-05-04 17:57 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Arun Easi, Daniel Wagner,
Roman Bolshakov, Himanshu Madhani, Martin Wilck,
Martin K. Petersen
From: Martin Wilck <mwilck@suse.com>
commit 856e152a3c08bf7987cbd41900741d83d9cddc8e upstream.
The purpose of the UNLOADING flag is to avoid port login procedures to
continue when a controller is in the process of shutting down. It makes
sense to set this flag before starting session teardown.
Furthermore, use atomic test_and_set_bit() to avoid the shutdown being run
multiple times in parallel. In qla2x00_disable_board_on_pci_error(), the
test for UNLOADING is postponed until after the check for an already
disabled PCI board.
Link: https://lore.kernel.org/r/20200421204621.19228-2-mwilck@suse.com
Fixes: 45235022da99 ("scsi: qla2xxx: Fix driver unload by shutting down chip")
Reviewed-by: Arun Easi <aeasi@marvell.com>
Reviewed-by: Daniel Wagner <dwagner@suse.de>
Reviewed-by: Roman Bolshakov <r.bolshakov@yadro.com>
Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
Signed-off-by: Martin Wilck <mwilck@suse.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/scsi/qla2xxx/qla_os.c | 32 ++++++++++++++------------------
1 file changed, 14 insertions(+), 18 deletions(-)
--- a/drivers/scsi/qla2xxx/qla_os.c
+++ b/drivers/scsi/qla2xxx/qla_os.c
@@ -3700,6 +3700,13 @@ qla2x00_remove_one(struct pci_dev *pdev)
}
qla2x00_wait_for_hba_ready(base_vha);
+ /*
+ * if UNLOADING flag is already set, then continue unload,
+ * where it was set first.
+ */
+ if (test_and_set_bit(UNLOADING, &base_vha->dpc_flags))
+ return;
+
if (IS_QLA25XX(ha) || IS_QLA2031(ha) || IS_QLA27XX(ha) ||
IS_QLA28XX(ha)) {
if (ha->flags.fw_started)
@@ -3718,15 +3725,6 @@ qla2x00_remove_one(struct pci_dev *pdev)
qla2x00_wait_for_sess_deletion(base_vha);
- /*
- * if UNLOAD flag is already set, then continue unload,
- * where it was set first.
- */
- if (test_bit(UNLOADING, &base_vha->dpc_flags))
- return;
-
- set_bit(UNLOADING, &base_vha->dpc_flags);
-
qla_nvme_delete(base_vha);
dma_free_coherent(&ha->pdev->dev,
@@ -6053,13 +6051,6 @@ qla2x00_disable_board_on_pci_error(struc
struct pci_dev *pdev = ha->pdev;
scsi_qla_host_t *base_vha = pci_get_drvdata(ha->pdev);
- /*
- * if UNLOAD flag is already set, then continue unload,
- * where it was set first.
- */
- if (test_bit(UNLOADING, &base_vha->dpc_flags))
- return;
-
ql_log(ql_log_warn, base_vha, 0x015b,
"Disabling adapter.\n");
@@ -6070,9 +6061,14 @@ qla2x00_disable_board_on_pci_error(struc
return;
}
- qla2x00_wait_for_sess_deletion(base_vha);
+ /*
+ * if UNLOADING flag is already set, then continue unload,
+ * where it was set first.
+ */
+ if (test_and_set_bit(UNLOADING, &base_vha->dpc_flags))
+ return;
- set_bit(UNLOADING, &base_vha->dpc_flags);
+ qla2x00_wait_for_sess_deletion(base_vha);
qla2x00_delete_all_vps(ha, base_vha);
^ permalink raw reply [flat|nested] 62+ messages in thread* [PATCH 5.4 35/57] scsi: qla2xxx: check UNLOADING before posting async work
2020-05-04 17:57 [PATCH 5.4 00/57] 5.4.39-rc1 review Greg Kroah-Hartman
` (33 preceding siblings ...)
2020-05-04 17:57 ` [PATCH 5.4 34/57] scsi: qla2xxx: set UNLOADING before waiting for session deletion Greg Kroah-Hartman
@ 2020-05-04 17:57 ` Greg Kroah-Hartman
2020-05-04 17:57 ` [PATCH 5.4 36/57] RDMA/mlx5: Set GRH fields in query QP on RoCE Greg Kroah-Hartman
` (25 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: Greg Kroah-Hartman @ 2020-05-04 17:57 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Arun Easi, Himanshu Madhani,
Martin Wilck, Martin K. Petersen
From: Martin Wilck <mwilck@suse.com>
commit 5a263892d7d0b4fe351363f8d1a14c6a75955475 upstream.
qlt_free_session_done() tries to post async PRLO / LOGO, and waits for the
completion of these async commands. If UNLOADING is set, this is doomed to
timeout, because the async logout command will never complete.
The only way to avoid waiting pointlessly is to fail posting these commands
in the first place if the driver is in UNLOADING state. In general,
posting any command should be avoided when the driver is UNLOADING.
With this patch, "rmmod qla2xxx" completes without noticeable delay.
Link: https://lore.kernel.org/r/20200421204621.19228-3-mwilck@suse.com
Fixes: 45235022da99 ("scsi: qla2xxx: Fix driver unload by shutting down chip")
Acked-by: Arun Easi <aeasi@marvell.com>
Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
Signed-off-by: Martin Wilck <mwilck@suse.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/scsi/qla2xxx/qla_os.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/scsi/qla2xxx/qla_os.c
+++ b/drivers/scsi/qla2xxx/qla_os.c
@@ -4857,6 +4857,9 @@ qla2x00_alloc_work(struct scsi_qla_host
struct qla_work_evt *e;
uint8_t bail;
+ if (test_bit(UNLOADING, &vha->dpc_flags))
+ return NULL;
+
QLA_VHA_MARK_BUSY(vha, bail);
if (bail)
return NULL;
^ permalink raw reply [flat|nested] 62+ messages in thread* [PATCH 5.4 36/57] RDMA/mlx5: Set GRH fields in query QP on RoCE
2020-05-04 17:57 [PATCH 5.4 00/57] 5.4.39-rc1 review Greg Kroah-Hartman
` (34 preceding siblings ...)
2020-05-04 17:57 ` [PATCH 5.4 35/57] scsi: qla2xxx: check UNLOADING before posting async work Greg Kroah-Hartman
@ 2020-05-04 17:57 ` Greg Kroah-Hartman
2020-05-04 17:57 ` [PATCH 5.4 37/57] RDMA/mlx4: Initialize ib_spec on the stack Greg Kroah-Hartman
` (24 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: Greg Kroah-Hartman @ 2020-05-04 17:57 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Aharon Landau, Maor Gottlieb,
Leon Romanovsky, Jason Gunthorpe
From: Aharon Landau <aharonl@mellanox.com>
commit 2d7e3ff7b6f2c614eb21d0dc348957a47eaffb57 upstream.
GRH fields such as sgid_index, hop limit, et. are set in the QP context
when QP is created/modified.
Currently, when query QP is performed, we fill the GRH fields only if the
GRH bit is set in the QP context, but this bit is not set for RoCE. Adjust
the check so we will set all relevant data for the RoCE too.
Since this data is returned to userspace, the below is an ABI regression.
Fixes: d8966fcd4c25 ("IB/core: Use rdma_ah_attr accessor functions")
Link: https://lore.kernel.org/r/20200413132028.930109-1-leon@kernel.org
Signed-off-by: Aharon Landau <aharonl@mellanox.com>
Reviewed-by: Maor Gottlieb <maorg@mellanox.com>
Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/infiniband/hw/mlx5/qp.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/infiniband/hw/mlx5/qp.c
+++ b/drivers/infiniband/hw/mlx5/qp.c
@@ -5496,7 +5496,9 @@ static void to_rdma_ah_attr(struct mlx5_
rdma_ah_set_path_bits(ah_attr, path->grh_mlid & 0x7f);
rdma_ah_set_static_rate(ah_attr,
path->static_rate ? path->static_rate - 5 : 0);
- if (path->grh_mlid & (1 << 7)) {
+
+ if (path->grh_mlid & (1 << 7) ||
+ ah_attr->type == RDMA_AH_ATTR_TYPE_ROCE) {
u32 tc_fl = be32_to_cpu(path->tclass_flowlabel);
rdma_ah_set_grh(ah_attr, NULL,
^ permalink raw reply [flat|nested] 62+ messages in thread* [PATCH 5.4 37/57] RDMA/mlx4: Initialize ib_spec on the stack
2020-05-04 17:57 [PATCH 5.4 00/57] 5.4.39-rc1 review Greg Kroah-Hartman
` (35 preceding siblings ...)
2020-05-04 17:57 ` [PATCH 5.4 36/57] RDMA/mlx5: Set GRH fields in query QP on RoCE Greg Kroah-Hartman
@ 2020-05-04 17:57 ` Greg Kroah-Hartman
2020-05-04 17:57 ` [PATCH 5.4 38/57] RDMA/siw: Fix potential siw_mem refcnt leak in siw_fastreg_mr() Greg Kroah-Hartman
` (23 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: Greg Kroah-Hartman @ 2020-05-04 17:57 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Alaa Hleihel, Maor Gottlieb,
Leon Romanovsky, Jason Gunthorpe
From: Alaa Hleihel <alaa@mellanox.com>
commit c08cfb2d8d78bfe81b37cc6ba84f0875bddd0d5c upstream.
Initialize ib_spec on the stack before using it, otherwise we will have
garbage values that will break creating default rules with invalid parsing
error.
Fixes: a37a1a428431 ("IB/mlx4: Add mechanism to support flow steering over IB links")
Link: https://lore.kernel.org/r/20200413132235.930642-1-leon@kernel.org
Signed-off-by: Alaa Hleihel <alaa@mellanox.com>
Reviewed-by: Maor Gottlieb <maorg@mellanox.com>
Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/infiniband/hw/mlx4/main.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/infiniband/hw/mlx4/main.c
+++ b/drivers/infiniband/hw/mlx4/main.c
@@ -1492,8 +1492,9 @@ static int __mlx4_ib_create_default_rule
int i;
for (i = 0; i < ARRAY_SIZE(pdefault_rules->rules_create_list); i++) {
+ union ib_flow_spec ib_spec = {};
int ret;
- union ib_flow_spec ib_spec;
+
switch (pdefault_rules->rules_create_list[i]) {
case 0:
/* no rule */
^ permalink raw reply [flat|nested] 62+ messages in thread* [PATCH 5.4 38/57] RDMA/siw: Fix potential siw_mem refcnt leak in siw_fastreg_mr()
2020-05-04 17:57 [PATCH 5.4 00/57] 5.4.39-rc1 review Greg Kroah-Hartman
` (36 preceding siblings ...)
2020-05-04 17:57 ` [PATCH 5.4 37/57] RDMA/mlx4: Initialize ib_spec on the stack Greg Kroah-Hartman
@ 2020-05-04 17:57 ` Greg Kroah-Hartman
2020-05-04 17:57 ` [PATCH 5.4 39/57] RDMA/core: Prevent mixed use of FDs between shared ufiles Greg Kroah-Hartman
` (22 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: Greg Kroah-Hartman @ 2020-05-04 17:57 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Xiyu Yang, Jason Gunthorpe
From: Jason Gunthorpe <jgg@mellanox.com>
commit 6e051971b0e2eeb0ce7ec65d3cc8180450512d36 upstream.
siw_fastreg_mr() invokes siw_mem_id2obj(), which returns a local reference
of the siw_mem object to "mem" with increased refcnt. When
siw_fastreg_mr() returns, "mem" becomes invalid, so the refcount should be
decreased to keep refcount balanced.
The issue happens in one error path of siw_fastreg_mr(). When "base_mr"
equals to NULL but "mem" is not NULL, the function forgets to decrease the
refcnt increased by siw_mem_id2obj() and causes a refcnt leak.
Reorganize the flow so that the goto unwind can be used as expected.
Fixes: b9be6f18cf9e ("rdma/siw: transmit path")
Link: https://lore.kernel.org/r/1586939949-69856-1-git-send-email-xiyuyang19@fudan.edu.cn
Reported-by: Xiyu Yang <xiyuyang19@fudan.edu.cn>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/infiniband/sw/siw/siw_qp_tx.c | 15 +++++++++++----
1 file changed, 11 insertions(+), 4 deletions(-)
--- a/drivers/infiniband/sw/siw/siw_qp_tx.c
+++ b/drivers/infiniband/sw/siw/siw_qp_tx.c
@@ -920,20 +920,27 @@ static int siw_fastreg_mr(struct ib_pd *
{
struct ib_mr *base_mr = (struct ib_mr *)(uintptr_t)sqe->base_mr;
struct siw_device *sdev = to_siw_dev(pd->device);
- struct siw_mem *mem = siw_mem_id2obj(sdev, sqe->rkey >> 8);
+ struct siw_mem *mem;
int rv = 0;
siw_dbg_pd(pd, "STag 0x%08x\n", sqe->rkey);
- if (unlikely(!mem || !base_mr)) {
+ if (unlikely(!base_mr)) {
pr_warn("siw: fastreg: STag 0x%08x unknown\n", sqe->rkey);
return -EINVAL;
}
+
if (unlikely(base_mr->rkey >> 8 != sqe->rkey >> 8)) {
pr_warn("siw: fastreg: STag 0x%08x: bad MR\n", sqe->rkey);
- rv = -EINVAL;
- goto out;
+ return -EINVAL;
+ }
+
+ mem = siw_mem_id2obj(sdev, sqe->rkey >> 8);
+ if (unlikely(!mem)) {
+ pr_warn("siw: fastreg: STag 0x%08x unknown\n", sqe->rkey);
+ return -EINVAL;
}
+
if (unlikely(mem->pd != pd)) {
pr_warn("siw: fastreg: PD mismatch\n");
rv = -EINVAL;
^ permalink raw reply [flat|nested] 62+ messages in thread* [PATCH 5.4 39/57] RDMA/core: Prevent mixed use of FDs between shared ufiles
2020-05-04 17:57 [PATCH 5.4 00/57] 5.4.39-rc1 review Greg Kroah-Hartman
` (37 preceding siblings ...)
2020-05-04 17:57 ` [PATCH 5.4 38/57] RDMA/siw: Fix potential siw_mem refcnt leak in siw_fastreg_mr() Greg Kroah-Hartman
@ 2020-05-04 17:57 ` Greg Kroah-Hartman
2020-05-04 17:57 ` [PATCH 5.4 40/57] RDMA/core: Fix race between destroy and release FD object Greg Kroah-Hartman
` (21 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: Greg Kroah-Hartman @ 2020-05-04 17:57 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Jason Gunthorpe, Leon Romanovsky
From: Leon Romanovsky <leonro@mellanox.com>
commit 0fb00941dc63990a10951146df216fc7b0e20bc2 upstream.
FDs can only be used on the ufile that created them, they cannot be mixed
to other ufiles. We are lacking a check to prevent it.
BUG: KASAN: null-ptr-deref in atomic64_sub_and_test include/asm-generic/atomic-instrumented.h:1547 [inline]
BUG: KASAN: null-ptr-deref in atomic_long_sub_and_test include/asm-generic/atomic-long.h:460 [inline]
BUG: KASAN: null-ptr-deref in fput_many+0x1a/0x140 fs/file_table.c:336
Write of size 8 at addr 0000000000000038 by task syz-executor179/284
CPU: 0 PID: 284 Comm: syz-executor179 Not tainted 5.5.0-rc5+ #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x94/0xce lib/dump_stack.c:118
__kasan_report+0x18f/0x1b7 mm/kasan/report.c:510
kasan_report+0xe/0x20 mm/kasan/common.c:639
check_memory_region_inline mm/kasan/generic.c:185 [inline]
check_memory_region+0x15d/0x1b0 mm/kasan/generic.c:192
atomic64_sub_and_test include/asm-generic/atomic-instrumented.h:1547 [inline]
atomic_long_sub_and_test include/asm-generic/atomic-long.h:460 [inline]
fput_many+0x1a/0x140 fs/file_table.c:336
rdma_lookup_put_uobject+0x85/0x130 drivers/infiniband/core/rdma_core.c:692
uobj_put_read include/rdma/uverbs_std_types.h:96 [inline]
_ib_uverbs_lookup_comp_file drivers/infiniband/core/uverbs_cmd.c:198 [inline]
create_cq+0x375/0xba0 drivers/infiniband/core/uverbs_cmd.c:1006
ib_uverbs_create_cq+0x114/0x140 drivers/infiniband/core/uverbs_cmd.c:1089
ib_uverbs_write+0xaa5/0xdf0 drivers/infiniband/core/uverbs_main.c:769
__vfs_write+0x7c/0x100 fs/read_write.c:494
vfs_write+0x168/0x4a0 fs/read_write.c:558
ksys_write+0xc8/0x200 fs/read_write.c:611
do_syscall_64+0x9c/0x390 arch/x86/entry/common.c:294
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x44ef99
Code: 00 b8 00 01 00 00 eb e1 e8 74 1c 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 c4 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007ffc0b74c028 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 00007ffc0b74c030 RCX: 000000000044ef99
RDX: 0000000000000040 RSI: 0000000020000040 RDI: 0000000000000005
RBP: 00007ffc0b74c038 R08: 0000000000401830 R09: 0000000000401830
R10: 00007ffc0b74c038 R11: 0000000000000246 R12: 0000000000000000
R13: 0000000000000000 R14: 00000000006be018 R15: 0000000000000000
Fixes: cf8966b3477d ("IB/core: Add support for fd objects")
Link: https://lore.kernel.org/r/20200421082929.311931-2-leon@kernel.org
Suggested-by: Jason Gunthorpe <jgg@mellanox.com>
Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/infiniband/core/rdma_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/infiniband/core/rdma_core.c
+++ b/drivers/infiniband/core/rdma_core.c
@@ -362,7 +362,7 @@ lookup_get_fd_uobject(const struct uverb
* and the caller is expected to ensure that uverbs_close_fd is never
* done while a call top lookup is possible.
*/
- if (f->f_op != fd_type->fops) {
+ if (f->f_op != fd_type->fops || uobject->ufile != ufile) {
fput(f);
return ERR_PTR(-EBADF);
}
^ permalink raw reply [flat|nested] 62+ messages in thread* [PATCH 5.4 40/57] RDMA/core: Fix race between destroy and release FD object
2020-05-04 17:57 [PATCH 5.4 00/57] 5.4.39-rc1 review Greg Kroah-Hartman
` (38 preceding siblings ...)
2020-05-04 17:57 ` [PATCH 5.4 39/57] RDMA/core: Prevent mixed use of FDs between shared ufiles Greg Kroah-Hartman
@ 2020-05-04 17:57 ` Greg Kroah-Hartman
2020-05-04 17:57 ` [PATCH 5.4 41/57] RDMA/cm: Fix ordering of xa_alloc_cyclic() in ib_create_cm_id() Greg Kroah-Hartman
` (20 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: Greg Kroah-Hartman @ 2020-05-04 17:57 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Jason Gunthorpe, Leon Romanovsky
From: Leon Romanovsky <leonro@mellanox.com>
commit f0abc761bbb9418876cc4d1ebc473e4ea6352e42 upstream.
The call to ->lookup_put() was too early and it caused an unlock of the
read/write protection of the uobject after the FD was put. This allows a
race:
CPU1 CPU2
rdma_lookup_put_uobject()
lookup_put_fd_uobject()
fput()
fput()
uverbs_uobject_fd_release()
WARN_ON(uverbs_try_lock_object(uobj,
UVERBS_LOOKUP_WRITE));
atomic_dec(usecnt)
Fix the code by changing the order, first unlock and call to
->lookup_put() after that.
Fixes: 3832125624b7 ("IB/core: Add support for idr types")
Link: https://lore.kernel.org/r/20200423060122.6182-1-leon@kernel.org
Suggested-by: Jason Gunthorpe <jgg@mellanox.com>
Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/infiniband/core/rdma_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/infiniband/core/rdma_core.c
+++ b/drivers/infiniband/core/rdma_core.c
@@ -689,7 +689,6 @@ void rdma_lookup_put_uobject(struct ib_u
enum rdma_lookup_mode mode)
{
assert_uverbs_usecnt(uobj, mode);
- uobj->uapi_object->type_class->lookup_put(uobj, mode);
/*
* In order to unlock an object, either decrease its usecnt for
* read access or zero it in case of exclusive access. See
@@ -706,6 +705,7 @@ void rdma_lookup_put_uobject(struct ib_u
break;
}
+ uobj->uapi_object->type_class->lookup_put(uobj, mode);
/* Pairs with the kref obtained by type->lookup_get */
uverbs_uobject_put(uobj);
}
^ permalink raw reply [flat|nested] 62+ messages in thread* [PATCH 5.4 41/57] RDMA/cm: Fix ordering of xa_alloc_cyclic() in ib_create_cm_id()
2020-05-04 17:57 [PATCH 5.4 00/57] 5.4.39-rc1 review Greg Kroah-Hartman
` (39 preceding siblings ...)
2020-05-04 17:57 ` [PATCH 5.4 40/57] RDMA/core: Fix race between destroy and release FD object Greg Kroah-Hartman
@ 2020-05-04 17:57 ` Greg Kroah-Hartman
2020-05-04 17:57 ` [PATCH 5.4 42/57] RDMA/cm: Fix an error check in cm_alloc_id_priv() Greg Kroah-Hartman
` (19 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: Greg Kroah-Hartman @ 2020-05-04 17:57 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Leon Romanovsky, Jason Gunthorpe
From: Jason Gunthorpe <jgg@mellanox.com>
commit e8dc4e885c459343970b25acd9320fe9ee5492e7 upstream.
xa_alloc_cyclic() is a SMP release to be paired with some later acquire
during xa_load() as part of cm_acquire_id().
As such, xa_alloc_cyclic() must be done after the cm_id is fully
initialized, in particular, it absolutely must be after the
refcount_set(), otherwise the refcount_inc() in cm_acquire_id() may not
see the set.
As there are several cases where a reader will be able to use the
id.local_id after cm_acquire_id in the IB_CM_IDLE state there needs to be
an unfortunate split into a NULL allocate and a finalizing xa_store.
Fixes: a977049dacde ("[PATCH] IB: Add the kernel CM implementation")
Link: https://lore.kernel.org/r/20200310092545.251365-2-leon@kernel.org
Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/infiniband/core/cm.c | 27 +++++++++++----------------
1 file changed, 11 insertions(+), 16 deletions(-)
--- a/drivers/infiniband/core/cm.c
+++ b/drivers/infiniband/core/cm.c
@@ -597,18 +597,6 @@ static int cm_init_av_by_path(struct sa_
return 0;
}
-static int cm_alloc_id(struct cm_id_private *cm_id_priv)
-{
- int err;
- u32 id;
-
- err = xa_alloc_cyclic_irq(&cm.local_id_table, &id, cm_id_priv,
- xa_limit_32b, &cm.local_id_next, GFP_KERNEL);
-
- cm_id_priv->id.local_id = (__force __be32)id ^ cm.random_id_operand;
- return err;
-}
-
static u32 cm_local_id(__be32 local_id)
{
return (__force u32) (local_id ^ cm.random_id_operand);
@@ -862,6 +850,7 @@ struct ib_cm_id *ib_create_cm_id(struct
void *context)
{
struct cm_id_private *cm_id_priv;
+ u32 id;
int ret;
cm_id_priv = kzalloc(sizeof *cm_id_priv, GFP_KERNEL);
@@ -873,9 +862,6 @@ struct ib_cm_id *ib_create_cm_id(struct
cm_id_priv->id.cm_handler = cm_handler;
cm_id_priv->id.context = context;
cm_id_priv->id.remote_cm_qpn = 1;
- ret = cm_alloc_id(cm_id_priv);
- if (ret)
- goto error;
spin_lock_init(&cm_id_priv->lock);
init_completion(&cm_id_priv->comp);
@@ -884,11 +870,20 @@ struct ib_cm_id *ib_create_cm_id(struct
INIT_LIST_HEAD(&cm_id_priv->altr_list);
atomic_set(&cm_id_priv->work_count, -1);
atomic_set(&cm_id_priv->refcount, 1);
+
+ ret = xa_alloc_cyclic_irq(&cm.local_id_table, &id, NULL, xa_limit_32b,
+ &cm.local_id_next, GFP_KERNEL);
+ if (ret)
+ goto error;
+ cm_id_priv->id.local_id = (__force __be32)id ^ cm.random_id_operand;
+ xa_store_irq(&cm.local_id_table, cm_local_id(cm_id_priv->id.local_id),
+ cm_id_priv, GFP_KERNEL);
+
return &cm_id_priv->id;
error:
kfree(cm_id_priv);
- return ERR_PTR(-ENOMEM);
+ return ERR_PTR(ret);
}
EXPORT_SYMBOL(ib_create_cm_id);
^ permalink raw reply [flat|nested] 62+ messages in thread* [PATCH 5.4 42/57] RDMA/cm: Fix an error check in cm_alloc_id_priv()
2020-05-04 17:57 [PATCH 5.4 00/57] 5.4.39-rc1 review Greg Kroah-Hartman
` (40 preceding siblings ...)
2020-05-04 17:57 ` [PATCH 5.4 41/57] RDMA/cm: Fix ordering of xa_alloc_cyclic() in ib_create_cm_id() Greg Kroah-Hartman
@ 2020-05-04 17:57 ` Greg Kroah-Hartman
2020-05-04 17:57 ` [PATCH 5.4 43/57] i2c: iproc: generate stop event for slave writes Greg Kroah-Hartman
` (18 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: Greg Kroah-Hartman @ 2020-05-04 17:57 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Dan Carpenter,
Matthew Wilcox (Oracle),
Jason Gunthorpe
From: Dan Carpenter <dan.carpenter@oracle.com>
commit 983653515849fb56b78ce55d349bb384d43030f6 upstream.
The xa_alloc_cyclic_irq() function returns either 0 or 1 on success and
negatives on error. This code treats 1 as an error and returns ERR_PTR(1)
which will cause an Oops in the caller.
Fixes: ae78ff3a0f0c ("RDMA/cm: Convert local_id_table to XArray")
Link: https://lore.kernel.org/r/20200407093714.GA80285@mwanda
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Matthew Wilcox (Oracle) <willy@infradead.org>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/infiniband/core/cm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/infiniband/core/cm.c
+++ b/drivers/infiniband/core/cm.c
@@ -873,7 +873,7 @@ struct ib_cm_id *ib_create_cm_id(struct
ret = xa_alloc_cyclic_irq(&cm.local_id_table, &id, NULL, xa_limit_32b,
&cm.local_id_next, GFP_KERNEL);
- if (ret)
+ if (ret < 0)
goto error;
cm_id_priv->id.local_id = (__force __be32)id ^ cm.random_id_operand;
xa_store_irq(&cm.local_id_table, cm_local_id(cm_id_priv->id.local_id),
^ permalink raw reply [flat|nested] 62+ messages in thread* [PATCH 5.4 43/57] i2c: iproc: generate stop event for slave writes
2020-05-04 17:57 [PATCH 5.4 00/57] 5.4.39-rc1 review Greg Kroah-Hartman
` (41 preceding siblings ...)
2020-05-04 17:57 ` [PATCH 5.4 42/57] RDMA/cm: Fix an error check in cm_alloc_id_priv() Greg Kroah-Hartman
@ 2020-05-04 17:57 ` Greg Kroah-Hartman
2020-05-04 17:57 ` [PATCH 5.4 44/57] vfio: avoid possible overflow in vfio_iommu_type1_pin_pages Greg Kroah-Hartman
` (17 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: Greg Kroah-Hartman @ 2020-05-04 17:57 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Rayagonda Kokatanur, Wolfram Sang
From: Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com>
commit 068143a8195fb0fdeea1f3ca430b3db0f6d04a53 upstream.
When slave status is I2C_SLAVE_RX_END, generate I2C_SLAVE_STOP
event to i2c_client.
Fixes: c245d94ed106 ("i2c: iproc: Add multi byte read-write support for slave mode")
Signed-off-by: Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/i2c/busses/i2c-bcm-iproc.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/i2c/busses/i2c-bcm-iproc.c
+++ b/drivers/i2c/busses/i2c-bcm-iproc.c
@@ -359,6 +359,9 @@ static bool bcm_iproc_i2c_slave_isr(stru
value = (u8)((val >> S_RX_DATA_SHIFT) & S_RX_DATA_MASK);
i2c_slave_event(iproc_i2c->slave,
I2C_SLAVE_WRITE_RECEIVED, &value);
+ if (rx_status == I2C_SLAVE_RX_END)
+ i2c_slave_event(iproc_i2c->slave,
+ I2C_SLAVE_STOP, &value);
}
} else if (status & BIT(IS_S_TX_UNDERRUN_SHIFT)) {
/* Master read other than start */
^ permalink raw reply [flat|nested] 62+ messages in thread* [PATCH 5.4 44/57] vfio: avoid possible overflow in vfio_iommu_type1_pin_pages
2020-05-04 17:57 [PATCH 5.4 00/57] 5.4.39-rc1 review Greg Kroah-Hartman
` (42 preceding siblings ...)
2020-05-04 17:57 ` [PATCH 5.4 43/57] i2c: iproc: generate stop event for slave writes Greg Kroah-Hartman
@ 2020-05-04 17:57 ` Greg Kroah-Hartman
2020-05-04 17:57 ` [PATCH 5.4 45/57] vfio/type1: Fix VA->PA translation for PFNMAP VMAs in vaddr_get_pfn() Greg Kroah-Hartman
` (16 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: Greg Kroah-Hartman @ 2020-05-04 17:57 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Yan Zhao, Alex Williamson
From: Yan Zhao <yan.y.zhao@intel.com>
commit 0ea971f8dcd6dee78a9a30ea70227cf305f11ff7 upstream.
add parentheses to avoid possible vaddr overflow.
Fixes: a54eb55045ae ("vfio iommu type1: Add support for mediated devices")
Signed-off-by: Yan Zhao <yan.y.zhao@intel.com>
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/vfio/vfio_iommu_type1.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/vfio/vfio_iommu_type1.c
+++ b/drivers/vfio/vfio_iommu_type1.c
@@ -593,7 +593,7 @@ static int vfio_iommu_type1_pin_pages(vo
continue;
}
- remote_vaddr = dma->vaddr + iova - dma->iova;
+ remote_vaddr = dma->vaddr + (iova - dma->iova);
ret = vfio_pin_page_external(dma, remote_vaddr, &phys_pfn[i],
do_accounting);
if (ret)
^ permalink raw reply [flat|nested] 62+ messages in thread* [PATCH 5.4 45/57] vfio/type1: Fix VA->PA translation for PFNMAP VMAs in vaddr_get_pfn()
2020-05-04 17:57 [PATCH 5.4 00/57] 5.4.39-rc1 review Greg Kroah-Hartman
` (43 preceding siblings ...)
2020-05-04 17:57 ` [PATCH 5.4 44/57] vfio: avoid possible overflow in vfio_iommu_type1_pin_pages Greg Kroah-Hartman
@ 2020-05-04 17:57 ` Greg Kroah-Hartman
2020-05-04 17:57 ` [PATCH 5.4 46/57] iommu/qcom: Fix local_base status check Greg Kroah-Hartman
` (15 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: Greg Kroah-Hartman @ 2020-05-04 17:57 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Sean Christopherson, Alex Williamson
From: Sean Christopherson <sean.j.christopherson@intel.com>
commit 5cbf3264bc715e9eb384e2b68601f8c02bb9a61d upstream.
Use follow_pfn() to get the PFN of a PFNMAP VMA instead of assuming that
vma->vm_pgoff holds the base PFN of the VMA. This fixes a bug where
attempting to do VFIO_IOMMU_MAP_DMA on an arbitrary PFNMAP'd region of
memory calculates garbage for the PFN.
Hilariously, this only got detected because the first "PFN" calculated
by vaddr_get_pfn() is PFN 0 (vma->vm_pgoff==0), and iommu_iova_to_phys()
uses PA==0 as an error, which triggers a WARN in vfio_unmap_unpin()
because the translation "failed". PFN 0 is now unconditionally reserved
on x86 in order to mitigate L1TF, which causes is_invalid_reserved_pfn()
to return true and in turns results in vaddr_get_pfn() returning success
for PFN 0. Eventually the bogus calculation runs into PFNs that aren't
reserved and leads to failure in vfio_pin_map_dma(). The subsequent
call to vfio_remove_dma() attempts to unmap PFN 0 and WARNs.
WARNING: CPU: 8 PID: 5130 at drivers/vfio/vfio_iommu_type1.c:750 vfio_unmap_unpin+0x2e1/0x310 [vfio_iommu_type1]
Modules linked in: vfio_pci vfio_virqfd vfio_iommu_type1 vfio ...
CPU: 8 PID: 5130 Comm: sgx Tainted: G W 5.6.0-rc5-705d787c7fee-vfio+ #3
Hardware name: Intel Corporation Mehlow UP Server Platform/Moss Beach Server, BIOS CNLSE2R1.D00.X119.B49.1803010910 03/01/2018
RIP: 0010:vfio_unmap_unpin+0x2e1/0x310 [vfio_iommu_type1]
Code: <0f> 0b 49 81 c5 00 10 00 00 e9 c5 fe ff ff bb 00 10 00 00 e9 3d fe
RSP: 0018:ffffbeb5039ebda8 EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffff9a55cbf8d480 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff9a52b771c200
RBP: 0000000000000000 R08: 0000000000000040 R09: 00000000fffffff2
R10: 0000000000000001 R11: ffff9a51fa896000 R12: 0000000184010000
R13: 0000000184000000 R14: 0000000000010000 R15: ffff9a55cb66ea08
FS: 00007f15d3830b40(0000) GS:ffff9a55d5600000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000561cf39429e0 CR3: 000000084f75f005 CR4: 00000000003626e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
vfio_remove_dma+0x17/0x70 [vfio_iommu_type1]
vfio_iommu_type1_ioctl+0x9e3/0xa7b [vfio_iommu_type1]
ksys_ioctl+0x92/0xb0
__x64_sys_ioctl+0x16/0x20
do_syscall_64+0x4c/0x180
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x7f15d04c75d7
Code: <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 81 48 2d 00 f7 d8 64 89 01 48
Fixes: 73fa0d10d077 ("vfio: Type1 IOMMU implementation")
Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/vfio/vfio_iommu_type1.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/vfio/vfio_iommu_type1.c
+++ b/drivers/vfio/vfio_iommu_type1.c
@@ -380,8 +380,8 @@ static int vaddr_get_pfn(struct mm_struc
vma = find_vma_intersection(mm, vaddr, vaddr + 1);
if (vma && vma->vm_flags & VM_PFNMAP) {
- *pfn = ((vaddr - vma->vm_start) >> PAGE_SHIFT) + vma->vm_pgoff;
- if (is_invalid_reserved_pfn(*pfn))
+ if (!follow_pfn(vma, vaddr, pfn) &&
+ is_invalid_reserved_pfn(*pfn))
ret = 0;
}
^ permalink raw reply [flat|nested] 62+ messages in thread* [PATCH 5.4 46/57] iommu/qcom: Fix local_base status check
2020-05-04 17:57 [PATCH 5.4 00/57] 5.4.39-rc1 review Greg Kroah-Hartman
` (44 preceding siblings ...)
2020-05-04 17:57 ` [PATCH 5.4 45/57] vfio/type1: Fix VA->PA translation for PFNMAP VMAs in vaddr_get_pfn() Greg Kroah-Hartman
@ 2020-05-04 17:57 ` Greg Kroah-Hartman
2020-05-04 17:57 ` [PATCH 5.4 47/57] scsi: target/iblock: fix WRITE SAME zeroing Greg Kroah-Hartman
` (14 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: Greg Kroah-Hartman @ 2020-05-04 17:57 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Tang Bin, Bjorn Andersson, Joerg Roedel
From: Tang Bin <tangbin@cmss.chinamobile.com>
commit b52649aee6243ea661905bdc5fbe28cc5f6dec76 upstream.
The function qcom_iommu_device_probe() does not perform sufficient
error checking after executing devm_ioremap_resource(), which can
result in crashes if a critical error path is encountered.
Fixes: 0ae349a0f33f ("iommu/qcom: Add qcom_iommu")
Signed-off-by: Tang Bin <tangbin@cmss.chinamobile.com>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20200418134703.1760-1-tangbin@cmss.chinamobile.com
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/iommu/qcom_iommu.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/drivers/iommu/qcom_iommu.c
+++ b/drivers/iommu/qcom_iommu.c
@@ -814,8 +814,11 @@ static int qcom_iommu_device_probe(struc
qcom_iommu->dev = dev;
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (res)
+ if (res) {
qcom_iommu->local_base = devm_ioremap_resource(dev, res);
+ if (IS_ERR(qcom_iommu->local_base))
+ return PTR_ERR(qcom_iommu->local_base);
+ }
qcom_iommu->iface_clk = devm_clk_get(dev, "iface");
if (IS_ERR(qcom_iommu->iface_clk)) {
^ permalink raw reply [flat|nested] 62+ messages in thread* [PATCH 5.4 47/57] scsi: target/iblock: fix WRITE SAME zeroing
2020-05-04 17:57 [PATCH 5.4 00/57] 5.4.39-rc1 review Greg Kroah-Hartman
` (45 preceding siblings ...)
2020-05-04 17:57 ` [PATCH 5.4 46/57] iommu/qcom: Fix local_base status check Greg Kroah-Hartman
@ 2020-05-04 17:57 ` Greg Kroah-Hartman
2020-05-04 17:57 ` [PATCH 5.4 48/57] iommu/amd: Fix legacy interrupt remapping for x2APIC-enabled system Greg Kroah-Hartman
` (13 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: Greg Kroah-Hartman @ 2020-05-04 17:57 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Bart Van Assche, David Disseldorp,
Martin K. Petersen
From: David Disseldorp <ddiss@suse.de>
commit 1d2ff149b263c9325875726a7804a0c75ef7112e upstream.
SBC4 specifies that WRITE SAME requests with the UNMAP bit set to zero
"shall perform the specified write operation to each LBA specified by the
command". Commit 2237498f0b5c ("target/iblock: Convert WRITE_SAME to
blkdev_issue_zeroout") modified the iblock backend to call
blkdev_issue_zeroout() when handling WRITE SAME requests with UNMAP=0 and a
zero data segment.
The iblock blkdev_issue_zeroout() call incorrectly provides a flags
parameter of 0 (bool false), instead of BLKDEV_ZERO_NOUNMAP. The bool
false parameter reflects the blkdev_issue_zeroout() API prior to commit
ee472d835c26 ("block: add a flags argument to (__)blkdev_issue_zeroout")
which was merged shortly before 2237498f0b5c.
Link: https://lore.kernel.org/r/20200419163109.11689-1-ddiss@suse.de
Fixes: 2237498f0b5c ("target/iblock: Convert WRITE_SAME to blkdev_issue_zeroout")
Reviewed-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: David Disseldorp <ddiss@suse.de>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/target/target_core_iblock.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/target/target_core_iblock.c
+++ b/drivers/target/target_core_iblock.c
@@ -432,7 +432,7 @@ iblock_execute_zero_out(struct block_dev
target_to_linux_sector(dev, cmd->t_task_lba),
target_to_linux_sector(dev,
sbc_get_write_same_sectors(cmd)),
- GFP_KERNEL, false);
+ GFP_KERNEL, BLKDEV_ZERO_NOUNMAP);
if (ret)
return TCM_LOGICAL_UNIT_COMMUNICATION_FAILURE;
^ permalink raw reply [flat|nested] 62+ messages in thread* [PATCH 5.4 48/57] iommu/amd: Fix legacy interrupt remapping for x2APIC-enabled system
2020-05-04 17:57 [PATCH 5.4 00/57] 5.4.39-rc1 review Greg Kroah-Hartman
` (46 preceding siblings ...)
2020-05-04 17:57 ` [PATCH 5.4 47/57] scsi: target/iblock: fix WRITE SAME zeroing Greg Kroah-Hartman
@ 2020-05-04 17:57 ` Greg Kroah-Hartman
2020-05-04 17:57 ` [PATCH 5.4 49/57] i2c: aspeed: Avoid i2c interrupt status clear race condition Greg Kroah-Hartman
` (12 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: Greg Kroah-Hartman @ 2020-05-04 17:57 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Suravee Suthikulpanit, Joerg Roedel
From: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
commit b74aa02d7a30ee5e262072a7d6e8deff10b37924 upstream.
Currently, system fails to boot because the legacy interrupt remapping
mode does not enable 128-bit IRTE (GA), which is required for x2APIC
support.
Fix by using AMD_IOMMU_GUEST_IR_LEGACY_GA mode when booting with
kernel option amd_iommu_intr=legacy instead. The initialization
logic will check GASup and automatically fallback to using
AMD_IOMMU_GUEST_IR_LEGACY if GA mode is not supported.
Fixes: 3928aa3f5775 ("iommu/amd: Detect and enable guest vAPIC support")
Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
Link: https://lore.kernel.org/r/1587562202-14183-1-git-send-email-suravee.suthikulpanit@amd.com
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/iommu/amd_iommu_init.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/iommu/amd_iommu_init.c
+++ b/drivers/iommu/amd_iommu_init.c
@@ -2946,7 +2946,7 @@ static int __init parse_amd_iommu_intr(c
{
for (; *str; ++str) {
if (strncmp(str, "legacy", 6) == 0) {
- amd_iommu_guest_ir = AMD_IOMMU_GUEST_IR_LEGACY;
+ amd_iommu_guest_ir = AMD_IOMMU_GUEST_IR_LEGACY_GA;
break;
}
if (strncmp(str, "vapic", 5) == 0) {
^ permalink raw reply [flat|nested] 62+ messages in thread* [PATCH 5.4 49/57] i2c: aspeed: Avoid i2c interrupt status clear race condition.
2020-05-04 17:57 [PATCH 5.4 00/57] 5.4.39-rc1 review Greg Kroah-Hartman
` (47 preceding siblings ...)
2020-05-04 17:57 ` [PATCH 5.4 48/57] iommu/amd: Fix legacy interrupt remapping for x2APIC-enabled system Greg Kroah-Hartman
@ 2020-05-04 17:57 ` Greg Kroah-Hartman
2020-05-04 17:57 ` [PATCH 5.4 50/57] ALSA: opti9xx: shut up gcc-10 range warning Greg Kroah-Hartman
` (11 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: Greg Kroah-Hartman @ 2020-05-04 17:57 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, ryan_chen, Benjamin Herrenschmidt,
Wolfram Sang
From: ryan_chen <ryan_chen@aspeedtech.com>
commit c926c87b8e36dcc0ea5c2a0a0227ed4f32d0516a upstream.
In AST2600 there have a slow peripheral bus between CPU and i2c
controller. Therefore GIC i2c interrupt status clear have delay timing,
when CPU issue write clear i2c controller interrupt status. To avoid
this issue, the driver need have read after write clear at i2c ISR.
Fixes: f327c686d3ba ("i2c: aspeed: added driver for Aspeed I2C")
Signed-off-by: ryan_chen <ryan_chen@aspeedtech.com>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
[wsa: added Fixes tag]
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/i2c/busses/i2c-aspeed.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/drivers/i2c/busses/i2c-aspeed.c
+++ b/drivers/i2c/busses/i2c-aspeed.c
@@ -603,6 +603,7 @@ static irqreturn_t aspeed_i2c_bus_irq(in
/* Ack all interrupts except for Rx done */
writel(irq_received & ~ASPEED_I2CD_INTR_RX_DONE,
bus->base + ASPEED_I2C_INTR_STS_REG);
+ readl(bus->base + ASPEED_I2C_INTR_STS_REG);
irq_remaining = irq_received;
#if IS_ENABLED(CONFIG_I2C_SLAVE)
@@ -645,9 +646,11 @@ static irqreturn_t aspeed_i2c_bus_irq(in
irq_received, irq_handled);
/* Ack Rx done */
- if (irq_received & ASPEED_I2CD_INTR_RX_DONE)
+ if (irq_received & ASPEED_I2CD_INTR_RX_DONE) {
writel(ASPEED_I2CD_INTR_RX_DONE,
bus->base + ASPEED_I2C_INTR_STS_REG);
+ readl(bus->base + ASPEED_I2C_INTR_STS_REG);
+ }
spin_unlock(&bus->lock);
return irq_remaining ? IRQ_NONE : IRQ_HANDLED;
}
^ permalink raw reply [flat|nested] 62+ messages in thread* [PATCH 5.4 50/57] ALSA: opti9xx: shut up gcc-10 range warning
2020-05-04 17:57 [PATCH 5.4 00/57] 5.4.39-rc1 review Greg Kroah-Hartman
` (48 preceding siblings ...)
2020-05-04 17:57 ` [PATCH 5.4 49/57] i2c: aspeed: Avoid i2c interrupt status clear race condition Greg Kroah-Hartman
@ 2020-05-04 17:57 ` Greg Kroah-Hartman
2020-05-04 17:57 ` [PATCH 5.4 51/57] Fix use after free in get_tree_bdev() Greg Kroah-Hartman
` (10 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: Greg Kroah-Hartman @ 2020-05-04 17:57 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Arnd Bergmann, Takashi Iwai
From: Arnd Bergmann <arnd@arndb.de>
commit 5ce00760a84848d008554c693ceb6286f4d9c509 upstream.
gcc-10 points out a few instances of suspicious integer arithmetic
leading to value truncation:
sound/isa/opti9xx/opti92x-ad1848.c: In function 'snd_opti9xx_configure':
sound/isa/opti9xx/opti92x-ad1848.c:322:43: error: overflow in conversion from 'int' to 'unsigned char' changes value from '(int)snd_opti9xx_read(chip, 3) & -256 | 240' to '240' [-Werror=overflow]
322 | (snd_opti9xx_read(chip, reg) & ~(mask)) | ((value) & (mask)))
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~
sound/isa/opti9xx/opti92x-ad1848.c:351:3: note: in expansion of macro 'snd_opti9xx_write_mask'
351 | snd_opti9xx_write_mask(chip, OPTi9XX_MC_REG(3), 0xf0, 0xff);
| ^~~~~~~~~~~~~~~~~~~~~~
sound/isa/opti9xx/miro.c: In function 'snd_miro_configure':
sound/isa/opti9xx/miro.c:873:40: error: overflow in conversion from 'int' to 'unsigned char' changes value from '(int)snd_miro_read(chip, 3) & -256 | 240' to '240' [-Werror=overflow]
873 | (snd_miro_read(chip, reg) & ~(mask)) | ((value) & (mask)))
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~
sound/isa/opti9xx/miro.c:1010:3: note: in expansion of macro 'snd_miro_write_mask'
1010 | snd_miro_write_mask(chip, OPTi9XX_MC_REG(3), 0xf0, 0xff);
| ^~~~~~~~~~~~~~~~~~~
These are all harmless here as only the low 8 bit are passed down
anyway. Change the macros to inline functions to make the code
more readable and also avoid the warning.
Strictly speaking those functions also need locking to make the
read/write pair atomic, but it seems unlikely that anyone would
still run into that issue.
Fixes: 1841f613fd2e ("[ALSA] Add snd-miro driver")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/r/20200429190216.85919-1-arnd@arndb.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
sound/isa/opti9xx/miro.c | 9 ++++++---
sound/isa/opti9xx/opti92x-ad1848.c | 9 ++++++---
2 files changed, 12 insertions(+), 6 deletions(-)
--- a/sound/isa/opti9xx/miro.c
+++ b/sound/isa/opti9xx/miro.c
@@ -867,10 +867,13 @@ static void snd_miro_write(struct snd_mi
spin_unlock_irqrestore(&chip->lock, flags);
}
+static inline void snd_miro_write_mask(struct snd_miro *chip,
+ unsigned char reg, unsigned char value, unsigned char mask)
+{
+ unsigned char oldval = snd_miro_read(chip, reg);
-#define snd_miro_write_mask(chip, reg, value, mask) \
- snd_miro_write(chip, reg, \
- (snd_miro_read(chip, reg) & ~(mask)) | ((value) & (mask)))
+ snd_miro_write(chip, reg, (oldval & ~mask) | (value & mask));
+}
/*
* Proc Interface
--- a/sound/isa/opti9xx/opti92x-ad1848.c
+++ b/sound/isa/opti9xx/opti92x-ad1848.c
@@ -317,10 +317,13 @@ static void snd_opti9xx_write(struct snd
}
-#define snd_opti9xx_write_mask(chip, reg, value, mask) \
- snd_opti9xx_write(chip, reg, \
- (snd_opti9xx_read(chip, reg) & ~(mask)) | ((value) & (mask)))
+static inline void snd_opti9xx_write_mask(struct snd_opti9xx *chip,
+ unsigned char reg, unsigned char value, unsigned char mask)
+{
+ unsigned char oldval = snd_opti9xx_read(chip, reg);
+ snd_opti9xx_write(chip, reg, (oldval & ~mask) | (value & mask));
+}
static int snd_opti9xx_configure(struct snd_opti9xx *chip,
long port,
^ permalink raw reply [flat|nested] 62+ messages in thread* [PATCH 5.4 51/57] Fix use after free in get_tree_bdev()
2020-05-04 17:57 [PATCH 5.4 00/57] 5.4.39-rc1 review Greg Kroah-Hartman
` (49 preceding siblings ...)
2020-05-04 17:57 ` [PATCH 5.4 50/57] ALSA: opti9xx: shut up gcc-10 range warning Greg Kroah-Hartman
@ 2020-05-04 17:57 ` Greg Kroah-Hartman
2020-05-04 17:57 ` [PATCH 5.4 52/57] nvme: prevent double free in nvme_alloc_ns() error handling Greg Kroah-Hartman
` (9 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: Greg Kroah-Hartman @ 2020-05-04 17:57 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Lukas Czerner, David Howells,
Ian Kent, Al Viro, Linus Torvalds
From: David Howells <dhowells@redhat.com>
commit dd7bc8158b413e0b580c491e8bd18cb91057c7c2 upstream.
Commit 6fcf0c72e4b9, a fix to get_tree_bdev() put a missing blkdev_put() in
the wrong place, before a warnf() that displays the bdev under
consideration rather after it.
This results in a silent lockup in printk("%pg") called via warnf() from
get_tree_bdev() under some circumstances when there's a race with the
blockdev being frozen. This can be caused by xfstests/tests/generic/085 in
combination with Lukas Czerner's ext4 mount API conversion patchset. It
looks like it ought to occur with other users of get_tree_bdev() such as
XFS, but apparently doesn't.
Fix this by switching the order of the lines.
Fixes: 6fcf0c72e4b9 ("vfs: add missing blkdev_put() in get_tree_bdev()")
Reported-by: Lukas Czerner <lczerner@redhat.com>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Ian Kent <raven@themaw.net>
cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/super.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/fs/super.c
+++ b/fs/super.c
@@ -1302,8 +1302,8 @@ int get_tree_bdev(struct fs_context *fc,
mutex_lock(&bdev->bd_fsfreeze_mutex);
if (bdev->bd_fsfreeze_count > 0) {
mutex_unlock(&bdev->bd_fsfreeze_mutex);
- blkdev_put(bdev, mode);
warnf(fc, "%pg: Can't mount, blockdev is frozen", bdev);
+ blkdev_put(bdev, mode);
return -EBUSY;
}
^ permalink raw reply [flat|nested] 62+ messages in thread* [PATCH 5.4 52/57] nvme: prevent double free in nvme_alloc_ns() error handling
2020-05-04 17:57 [PATCH 5.4 00/57] 5.4.39-rc1 review Greg Kroah-Hartman
` (50 preceding siblings ...)
2020-05-04 17:57 ` [PATCH 5.4 51/57] Fix use after free in get_tree_bdev() Greg Kroah-Hartman
@ 2020-05-04 17:57 ` Greg Kroah-Hartman
2020-05-04 17:57 ` [PATCH 5.4 53/57] nfs: Fix potential posix_acl refcnt leak in nfs3_set_acl Greg Kroah-Hartman
` (8 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: Greg Kroah-Hartman @ 2020-05-04 17:57 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Niklas Cassel, Christoph Hellwig
From: Niklas Cassel <niklas.cassel@wdc.com>
commit 132be62387c7a72a38872676c18b0dfae264adb8 upstream.
When jumping to the out_put_disk label, we will call put_disk(), which will
trigger a call to disk_release(), which calls blk_put_queue().
Later in the cleanup code, we do blk_cleanup_queue(), which will also call
blk_put_queue().
Putting the queue twice is incorrect, and will generate a KASAN splat.
Set the disk->queue pointer to NULL, before calling put_disk(), so that the
first call to blk_put_queue() will not free the queue.
The second call to blk_put_queue() uses another pointer to the same queue,
so this call will still free the queue.
Fixes: 85136c010285 ("lightnvm: simplify geometry enumeration")
Signed-off-by: Niklas Cassel <niklas.cassel@wdc.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/nvme/host/core.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/nvme/host/core.c
+++ b/drivers/nvme/host/core.c
@@ -3566,6 +3566,8 @@ static int nvme_alloc_ns(struct nvme_ctr
return 0;
out_put_disk:
+ /* prevent double queue cleanup */
+ ns->disk->queue = NULL;
put_disk(ns->disk);
out_unlink_ns:
mutex_lock(&ctrl->subsys->lock);
^ permalink raw reply [flat|nested] 62+ messages in thread* [PATCH 5.4 53/57] nfs: Fix potential posix_acl refcnt leak in nfs3_set_acl
2020-05-04 17:57 [PATCH 5.4 00/57] 5.4.39-rc1 review Greg Kroah-Hartman
` (51 preceding siblings ...)
2020-05-04 17:57 ` [PATCH 5.4 52/57] nvme: prevent double free in nvme_alloc_ns() error handling Greg Kroah-Hartman
@ 2020-05-04 17:57 ` Greg Kroah-Hartman
2020-05-04 17:57 ` [PATCH 5.4 54/57] dmaengine: dmatest: Fix iteration non-stop logic Greg Kroah-Hartman
` (7 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: Greg Kroah-Hartman @ 2020-05-04 17:57 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Xiyu Yang, Andreas Gruenbacher,
Trond Myklebust
From: Andreas Gruenbacher <agruenba@redhat.com>
commit 7648f939cb919b9d15c21fff8cd9eba908d595dc upstream.
nfs3_set_acl keeps track of the acl it allocated locally to determine if an acl
needs to be released at the end. This results in a memory leak when the
function allocates an acl as well as a default acl. Fix by releasing acls
that differ from the acl originally passed into nfs3_set_acl.
Fixes: b7fa0554cf1b ("[PATCH] NFS: Add support for NFSv3 ACLs")
Reported-by: Xiyu Yang <xiyuyang19@fudan.edu.cn>
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/nfs/nfs3acl.c | 22 +++++++++++++++-------
1 file changed, 15 insertions(+), 7 deletions(-)
--- a/fs/nfs/nfs3acl.c
+++ b/fs/nfs/nfs3acl.c
@@ -253,37 +253,45 @@ int nfs3_proc_setacls(struct inode *inod
int nfs3_set_acl(struct inode *inode, struct posix_acl *acl, int type)
{
- struct posix_acl *alloc = NULL, *dfacl = NULL;
+ struct posix_acl *orig = acl, *dfacl = NULL, *alloc;
int status;
if (S_ISDIR(inode->i_mode)) {
switch(type) {
case ACL_TYPE_ACCESS:
- alloc = dfacl = get_acl(inode, ACL_TYPE_DEFAULT);
+ alloc = get_acl(inode, ACL_TYPE_DEFAULT);
if (IS_ERR(alloc))
goto fail;
+ dfacl = alloc;
break;
case ACL_TYPE_DEFAULT:
- dfacl = acl;
- alloc = acl = get_acl(inode, ACL_TYPE_ACCESS);
+ alloc = get_acl(inode, ACL_TYPE_ACCESS);
if (IS_ERR(alloc))
goto fail;
+ dfacl = acl;
+ acl = alloc;
break;
}
}
if (acl == NULL) {
- alloc = acl = posix_acl_from_mode(inode->i_mode, GFP_KERNEL);
+ alloc = posix_acl_from_mode(inode->i_mode, GFP_KERNEL);
if (IS_ERR(alloc))
goto fail;
+ acl = alloc;
}
status = __nfs3_proc_setacls(inode, acl, dfacl);
- posix_acl_release(alloc);
+out:
+ if (acl != orig)
+ posix_acl_release(acl);
+ if (dfacl != orig)
+ posix_acl_release(dfacl);
return status;
fail:
- return PTR_ERR(alloc);
+ status = PTR_ERR(alloc);
+ goto out;
}
const struct xattr_handler *nfs3_xattr_handlers[] = {
^ permalink raw reply [flat|nested] 62+ messages in thread* [PATCH 5.4 54/57] dmaengine: dmatest: Fix iteration non-stop logic
2020-05-04 17:57 [PATCH 5.4 00/57] 5.4.39-rc1 review Greg Kroah-Hartman
` (52 preceding siblings ...)
2020-05-04 17:57 ` [PATCH 5.4 53/57] nfs: Fix potential posix_acl refcnt leak in nfs3_set_acl Greg Kroah-Hartman
@ 2020-05-04 17:57 ` Greg Kroah-Hartman
2020-05-04 17:57 ` [PATCH 5.4 55/57] dmaengine: dmatest: Fix process hang when reading wait parameter Greg Kroah-Hartman
` (6 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: Greg Kroah-Hartman @ 2020-05-04 17:57 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Dan Williams, Nicolas Ferre,
Andy Shevchenko, Vinod Koul
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
commit b9f960201249f20deea586b4ec814669b4c6b1c0 upstream.
Under some circumstances, i.e. when test is still running and about to
time out and user runs, for example,
grep -H . /sys/module/dmatest/parameters/*
the iterations parameter is not respected and test is going on and on until
user gives
echo 0 > /sys/module/dmatest/parameters/run
This is not what expected.
The history of this bug is interesting. I though that the commit
2d88ce76eb98 ("dmatest: add a 'wait' parameter")
is a culprit, but looking closer to the code I think it simple revealed the
broken logic from the day one, i.e. in the commit
0a2ff57d6fba ("dmaengine: dmatest: add a maximum number of test iterations")
which adds iterations parameter.
So, to the point, the conditional of checking the thread to be stopped being
first part of conjunction logic prevents to check iterations. Thus, we have to
always check both conditions to be able to stop after given iterations.
Since it wasn't visible before second commit appeared, I add a respective
Fixes tag.
Fixes: 2d88ce76eb98 ("dmatest: add a 'wait' parameter")
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Nicolas Ferre <nicolas.ferre@microchip.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
Link: https://lore.kernel.org/r/20200424161147.16895-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/dma/dmatest.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/dma/dmatest.c
+++ b/drivers/dma/dmatest.c
@@ -662,8 +662,8 @@ static int dmatest_func(void *data)
flags = DMA_CTRL_ACK | DMA_PREP_INTERRUPT;
ktime = ktime_get();
- while (!kthread_should_stop()
- && !(params->iterations && total_tests >= params->iterations)) {
+ while (!(kthread_should_stop() ||
+ (params->iterations && total_tests >= params->iterations))) {
struct dma_async_tx_descriptor *tx = NULL;
struct dmaengine_unmap_data *um;
dma_addr_t *dsts;
^ permalink raw reply [flat|nested] 62+ messages in thread* [PATCH 5.4 55/57] dmaengine: dmatest: Fix process hang when reading wait parameter
2020-05-04 17:57 [PATCH 5.4 00/57] 5.4.39-rc1 review Greg Kroah-Hartman
` (53 preceding siblings ...)
2020-05-04 17:57 ` [PATCH 5.4 54/57] dmaengine: dmatest: Fix iteration non-stop logic Greg Kroah-Hartman
@ 2020-05-04 17:57 ` Greg Kroah-Hartman
2020-05-04 17:58 ` [PATCH 5.4 56/57] arm64: vdso: Add -fasynchronous-unwind-tables to cflags Greg Kroah-Hartman
` (5 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: Greg Kroah-Hartman @ 2020-05-04 17:57 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Seraj Alijan, Andy Shevchenko, Vinod Koul
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
commit aa72f1d20ee973d68f26d46fce5e1cf6f9b7e1ca upstream.
If we do
% echo 1 > /sys/module/dmatest/parameters/run
[ 115.851124] dmatest: Could not start test, no channels configured
% echo dma8chan7 > /sys/module/dmatest/parameters/channel
[ 127.563872] dmatest: Added 1 threads using dma8chan7
% cat /sys/module/dmatest/parameters/wait
... !!! HANG !!! ...
The culprit is the commit 6138f967bccc
("dmaengine: dmatest: Use fixed point div to calculate iops")
which makes threads not to run, but pending and being kicked off by writing
to the 'run' node. However, it forgot to consider 'wait' routine to avoid
above mentioned case.
In order to fix this, check for really running threads, i.e. with pending
and done flags unset.
It's pity the culprit commit hadn't updated documentation and tested all
possible scenarios.
Fixes: 6138f967bccc ("dmaengine: dmatest: Use fixed point div to calculate iops")
Cc: Seraj Alijan <seraj.alijan@sondrel.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20200428113518.70620-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/dma/dmatest.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/dma/dmatest.c
+++ b/drivers/dma/dmatest.c
@@ -240,7 +240,7 @@ static bool is_threaded_test_run(struct
struct dmatest_thread *thread;
list_for_each_entry(thread, &dtc->threads, node) {
- if (!thread->done)
+ if (!thread->done && !thread->pending)
return true;
}
}
^ permalink raw reply [flat|nested] 62+ messages in thread* [PATCH 5.4 56/57] arm64: vdso: Add -fasynchronous-unwind-tables to cflags
2020-05-04 17:57 [PATCH 5.4 00/57] 5.4.39-rc1 review Greg Kroah-Hartman
` (54 preceding siblings ...)
2020-05-04 17:57 ` [PATCH 5.4 55/57] dmaengine: dmatest: Fix process hang when reading wait parameter Greg Kroah-Hartman
@ 2020-05-04 17:58 ` Greg Kroah-Hartman
2020-05-04 17:58 ` [PATCH 5.4 57/57] selinux: properly handle multiple messages in selinux_netlink_send() Greg Kroah-Hartman
` (4 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: Greg Kroah-Hartman @ 2020-05-04 17:58 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Will Deacon, Szabolcs Nagy,
Vincenzo Frascino, Catalin Marinas
From: Vincenzo Frascino <vincenzo.frascino@arm.com>
commit 1578e5d03112e3e9d37e1c4d95b6dfb734c73955 upstream.
On arm64 linux gcc uses -fasynchronous-unwind-tables -funwind-tables
by default since gcc-8, so now the de facto platform ABI is to allow
unwinding from async signal handlers.
However on bare metal targets (aarch64-none-elf), and on old gcc,
async and sync unwind tables are not enabled by default to avoid
runtime memory costs.
This means if linux is built with a baremetal toolchain the vdso.so
may not have unwind tables which breaks the gcc platform ABI guarantee
in userspace.
Add -fasynchronous-unwind-tables explicitly to the vgettimeofday.o
cflags to address the ABI change.
Fixes: 28b1a824a4f4 ("arm64: vdso: Substitute gettimeofday() with C implementation")
Cc: Will Deacon <will@kernel.org>
Reported-by: Szabolcs Nagy <szabolcs.nagy@arm.com>
Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm64/kernel/vdso/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/arm64/kernel/vdso/Makefile
+++ b/arch/arm64/kernel/vdso/Makefile
@@ -32,7 +32,7 @@ UBSAN_SANITIZE := n
OBJECT_FILES_NON_STANDARD := y
KCOV_INSTRUMENT := n
-CFLAGS_vgettimeofday.o = -O2 -mcmodel=tiny
+CFLAGS_vgettimeofday.o = -O2 -mcmodel=tiny -fasynchronous-unwind-tables
ifneq ($(c-gettimeofday-y),)
CFLAGS_vgettimeofday.o += -include $(c-gettimeofday-y)
^ permalink raw reply [flat|nested] 62+ messages in thread* [PATCH 5.4 57/57] selinux: properly handle multiple messages in selinux_netlink_send()
2020-05-04 17:57 [PATCH 5.4 00/57] 5.4.39-rc1 review Greg Kroah-Hartman
` (55 preceding siblings ...)
2020-05-04 17:58 ` [PATCH 5.4 56/57] arm64: vdso: Add -fasynchronous-unwind-tables to cflags Greg Kroah-Hartman
@ 2020-05-04 17:58 ` Greg Kroah-Hartman
2020-05-05 8:38 ` [PATCH 5.4 00/57] 5.4.39-rc1 review Jon Hunter
` (3 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: Greg Kroah-Hartman @ 2020-05-04 17:58 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Dmitry Vyukov, Stephen Smalley, Paul Moore
From: Paul Moore <paul@paul-moore.com>
commit fb73974172ffaaf57a7c42f35424d9aece1a5af6 upstream.
Fix the SELinux netlink_send hook to properly handle multiple netlink
messages in a single sk_buff; each message is parsed and subject to
SELinux access control. Prior to this patch, SELinux only inspected
the first message in the sk_buff.
Cc: stable@vger.kernel.org
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Reviewed-by: Stephen Smalley <stephen.smalley.work@gmail.com>
Signed-off-by: Paul Moore <paul@paul-moore.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
security/selinux/hooks.c | 70 ++++++++++++++++++++++++++++++-----------------
1 file changed, 45 insertions(+), 25 deletions(-)
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -5521,40 +5521,60 @@ static int selinux_tun_dev_open(void *se
static int selinux_nlmsg_perm(struct sock *sk, struct sk_buff *skb)
{
- int err = 0;
- u32 perm;
+ int rc = 0;
+ unsigned int msg_len;
+ unsigned int data_len = skb->len;
+ unsigned char *data = skb->data;
struct nlmsghdr *nlh;
struct sk_security_struct *sksec = sk->sk_security;
+ u16 sclass = sksec->sclass;
+ u32 perm;
- if (skb->len < NLMSG_HDRLEN) {
- err = -EINVAL;
- goto out;
- }
- nlh = nlmsg_hdr(skb);
+ while (data_len >= nlmsg_total_size(0)) {
+ nlh = (struct nlmsghdr *)data;
- err = selinux_nlmsg_lookup(sksec->sclass, nlh->nlmsg_type, &perm);
- if (err) {
- if (err == -EINVAL) {
+ /* NOTE: the nlmsg_len field isn't reliably set by some netlink
+ * users which means we can't reject skb's with bogus
+ * length fields; our solution is to follow what
+ * netlink_rcv_skb() does and simply skip processing at
+ * messages with length fields that are clearly junk
+ */
+ if (nlh->nlmsg_len < NLMSG_HDRLEN || nlh->nlmsg_len > data_len)
+ return 0;
+
+ rc = selinux_nlmsg_lookup(sclass, nlh->nlmsg_type, &perm);
+ if (rc == 0) {
+ rc = sock_has_perm(sk, perm);
+ if (rc)
+ return rc;
+ } else if (rc == -EINVAL) {
+ /* -EINVAL is a missing msg/perm mapping */
pr_warn_ratelimited("SELinux: unrecognized netlink"
- " message: protocol=%hu nlmsg_type=%hu sclass=%s"
- " pig=%d comm=%s\n",
- sk->sk_protocol, nlh->nlmsg_type,
- secclass_map[sksec->sclass - 1].name,
- task_pid_nr(current), current->comm);
- if (!enforcing_enabled(&selinux_state) ||
- security_get_allow_unknown(&selinux_state))
- err = 0;
+ " message: protocol=%hu nlmsg_type=%hu sclass=%s"
+ " pid=%d comm=%s\n",
+ sk->sk_protocol, nlh->nlmsg_type,
+ secclass_map[sclass - 1].name,
+ task_pid_nr(current), current->comm);
+ if (enforcing_enabled(&selinux_state) &&
+ !security_get_allow_unknown(&selinux_state))
+ return rc;
+ rc = 0;
+ } else if (rc == -ENOENT) {
+ /* -ENOENT is a missing socket/class mapping, ignore */
+ rc = 0;
+ } else {
+ return rc;
}
- /* Ignore */
- if (err == -ENOENT)
- err = 0;
- goto out;
+ /* move to the next message after applying netlink padding */
+ msg_len = NLMSG_ALIGN(nlh->nlmsg_len);
+ if (msg_len >= data_len)
+ return 0;
+ data_len -= msg_len;
+ data += msg_len;
}
- err = sock_has_perm(sk, perm);
-out:
- return err;
+ return rc;
}
#ifdef CONFIG_NETFILTER
^ permalink raw reply [flat|nested] 62+ messages in thread* Re: [PATCH 5.4 00/57] 5.4.39-rc1 review
2020-05-04 17:57 [PATCH 5.4 00/57] 5.4.39-rc1 review Greg Kroah-Hartman
` (56 preceding siblings ...)
2020-05-04 17:58 ` [PATCH 5.4 57/57] selinux: properly handle multiple messages in selinux_netlink_send() Greg Kroah-Hartman
@ 2020-05-05 8:38 ` Jon Hunter
2020-05-05 15:19 ` Naresh Kamboju
` (2 subsequent siblings)
60 siblings, 0 replies; 62+ messages in thread
From: Jon Hunter @ 2020-05-05 8:38 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-kernel
Cc: torvalds, akpm, linux, shuah, patches, ben.hutchings,
lkft-triage, stable, linux-tegra
On 04/05/2020 18:57, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.4.39 release.
> There are 57 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed, 06 May 2020 16:52:55 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.39-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.4.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
All tests are passing for Tegra ...
Test results for stable-v5.4:
13 builds: 13 pass, 0 fail
24 boots: 24 pass, 0 fail
40 tests: 40 pass, 0 fail
Linux version: 5.4.39-rc1-g29ca49e0243b
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
tegra194-p2972-0000, tegra20-ventana,
tegra210-p2371-2180, tegra210-p3450-0000,
tegra30-cardhu-a04
Cheers
Jon
--
nvpublic
^ permalink raw reply [flat|nested] 62+ messages in thread* Re: [PATCH 5.4 00/57] 5.4.39-rc1 review
2020-05-04 17:57 [PATCH 5.4 00/57] 5.4.39-rc1 review Greg Kroah-Hartman
` (57 preceding siblings ...)
2020-05-05 8:38 ` [PATCH 5.4 00/57] 5.4.39-rc1 review Jon Hunter
@ 2020-05-05 15:19 ` Naresh Kamboju
2020-05-05 15:43 ` Guenter Roeck
2020-05-05 15:44 ` shuah
60 siblings, 0 replies; 62+ messages in thread
From: Naresh Kamboju @ 2020-05-05 15:19 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: open list, Linus Torvalds, Andrew Morton, Guenter Roeck,
Shuah Khan, patches, Ben Hutchings, lkft-triage, linux- stable
On Mon, 4 May 2020 at 23:33, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> This is the start of the stable review cycle for the 5.4.39 release.
> There are 57 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed, 06 May 2020 16:52:55 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.39-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.4.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>
Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.
NOTE:
While running LTP mm tests on hikey device kernel panic has been noticed.
But this is hard to reproduce.
We are investigating this problem.
[ 75.934817] Unable to handle kernel NULL pointer dereference at
virtual address 0000000000000000
[ 75.943910] Mem abort info:
[ 75.946768] ESR = 0x86000006
[ 75.949899] EC = 0x21: IABT (current EL), IL = 32 bits
[ 75.955330] SET = 0, FnV = 0
[ 75.958454] EA = 0, S1PTW = 0
[ 75.961674] user pgtable: 4k pages, 48-bit VAs, pgdp=000000007296d000
[ 75.968260] [0000000000000000] pgd=0000000072962003,
pud=0000000072935003, pmd=0000000000000000
[ 75.977159] Internal error: Oops: 86000006 [#1] PREEMPT SMP
[ 75.982851] Modules linked in: wl18xx wlcore mac80211 cfg80211
hci_uart snd_soc_audio_graph_card btbcm crct10dif_ce adv7511
snd_soc_simple_card_utils wlcore_sdio cec kirin_drm dw_drm_dsi
bluetooth drm_kms_helper rfkill drm fuse
[ 75.998113] dwmmc_k3 f723d000.dwmmc0: Unexpected interrupt latency
[ 76.003485] CPU: 0 PID: 0 Comm: swapper/0 Not tainted
5.4.39-rc1-00058-g29ca49e0243b #1
[ 76.017981] Hardware name: HiKey Development Board (DT)
[ 76.024656] pstate: 60000085 (nZCv daIf -PAN -UAO)
[ 76.029554] pc : 0x0
[ 76.031796] lr : cpuidle_enter_state+0x68/0x360
<>
[ 76.121215] Call trace:
[ 76.123718] 0x0
[ 76.125604] cpuidle_enter+0x34/0x48
[ 76.129262] call_cpuidle+0x18/0x38
[ 76.132830] do_idle+0x1e0/0x280
[ 76.136129] cpu_startup_entry+0x20/0x40
[ 76.140139] rest_init+0xd4/0xe0
[ 76.143442] arch_call_rest_init+0xc/0x14
[ 76.147540] start_kernel+0x41c/0x448
[ 76.151293] Code: bad PC value
[ 76.154426] ---[ end trace 01a359b3eb02445a ]---
[ 76.159146] Kernel panic - not syncing: Attempted to kill the idle task!
[ 76.165995] SMP: stopping secondary CPUs
[ 76.170441] Kernel Offset: disabled
[ 76.174005] CPU features: 0x0002,24002004
[ 76.178103] Memory Limit: none
[ 76.181240] ---[ end Kernel panic - not syncing: Attempted to kill
the idle task! ]---
[ 75.977159] Internal error: Oops: 86000006 [#1] PREEMPT SMP
Summary
------------------------------------------------------------------------
kernel: 5.4.39-rc1
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-5.4.y
git commit: 29ca49e0243b0d2bb55a2ee418f3cdc1fae69627
git describe: v5.4.38-58-g29ca49e0243b
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-5.4-oe/build/v5.4.38-58-g29ca49e0243b
No regressions (compared to build v5.4.38)
No fixes (compared to build v5.4.38)
Ran 25955 total tests in the following environments and test suites.
Environments
--------------
- dragonboard-410c
- hi6220-hikey
- i386
- juno-r2
- juno-r2-compat
- juno-r2-kasan
- nxp-ls2088
- qemu_arm
- qemu_arm64
- qemu_i386
- qemu_x86_64
- x15
- x86
- x86-kasan
Test Suites
-----------
* build
* install-android-platform-tools-r2600
* install-android-platform-tools-r2800
* libgpiod
* linux-log-parser
* ltp-commands-tests
* ltp-containers-tests
* ltp-cve-tests
* ltp-math-tests
* ltp-sched-tests
* perf
* kselftest
* kselftest/drivers
* kselftest/filesystems
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-securebits-tests
* v4l2-compliance
* kselftest/net
* kselftest/networking
* libhugetlbfs
* ltp-cap_bounds-tests
* ltp-cpuhotplug-tests
* ltp-crypto-tests
* ltp-ipc-tests
* ltp-mm-tests
* ltp-open-posix-tests
* ltp-syscalls-tests
* network-basic-tests
* kvm-unit-tests
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-native/drivers
* kselftest-vsyscall-mode-native/filesystems
* kselftest-vsyscall-mode-native/net
* kselftest-vsyscall-mode-native/networking
* kselftest-vsyscall-mode-none
* kselftest-vsyscall-mode-none/drivers
* kselftest-vsyscall-mode-none/filesystems
* kselftest-vsyscall-mode-none/net
* kselftest-vsyscall-mode-none/networking
--
Linaro LKFT
https://lkft.linaro.org
^ permalink raw reply [flat|nested] 62+ messages in thread* Re: [PATCH 5.4 00/57] 5.4.39-rc1 review
2020-05-04 17:57 [PATCH 5.4 00/57] 5.4.39-rc1 review Greg Kroah-Hartman
` (58 preceding siblings ...)
2020-05-05 15:19 ` Naresh Kamboju
@ 2020-05-05 15:43 ` Guenter Roeck
2020-05-05 15:44 ` shuah
60 siblings, 0 replies; 62+ messages in thread
From: Guenter Roeck @ 2020-05-05 15:43 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-kernel
Cc: torvalds, akpm, shuah, patches, ben.hutchings, lkft-triage, stable
On 5/4/20 10:57 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.4.39 release.
> There are 57 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed, 06 May 2020 16:52:55 +0000.
> Anything received after that time might be too late.
>
Build results:
total: 157 pass: 157 fail: 0
Qemu test results:
total: 426 pass: 426 fail: 0
Guenter
^ permalink raw reply [flat|nested] 62+ messages in thread* Re: [PATCH 5.4 00/57] 5.4.39-rc1 review
2020-05-04 17:57 [PATCH 5.4 00/57] 5.4.39-rc1 review Greg Kroah-Hartman
` (59 preceding siblings ...)
2020-05-05 15:43 ` Guenter Roeck
@ 2020-05-05 15:44 ` shuah
60 siblings, 0 replies; 62+ messages in thread
From: shuah @ 2020-05-05 15:44 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-kernel
Cc: torvalds, akpm, linux, patches, ben.hutchings, lkft-triage,
stable, shuah
On 5/4/20 11:57 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.4.39 release.
> There are 57 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed, 06 May 2020 16:52:55 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.39-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.4.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>
Compiled and booted on my test system. No dmesg regressions.
thanks,
-- Shuah
^ permalink raw reply [flat|nested] 62+ messages in thread