December 2017 - Linux-stable-mirror

[Linux-stable-mirror] Patch "drm: safely free connectors from connector_iter" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled drm: safely free connectors from connector_iter to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: drm-safely-free-connectors-from-connector_iter.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From a703c55004e1c5076d57e43771b3e11117796ea0 Mon Sep 17 00:00:00 2001 From: Daniel Vetter <daniel.vetter(a)ffwll.ch> Date: Mon, 4 Dec 2017 21:48:18 +0100 Subject: drm: safely free connectors from connector_iter From: Daniel Vetter <daniel.vetter(a)ffwll.ch> commit a703c55004e1c5076d57e43771b3e11117796ea0 upstream. In commit 613051dac40da1751ab269572766d3348d45a197 Author: Daniel Vetter <daniel.vetter(a)ffwll.ch> Date: Wed Dec 14 00:08:06 2016 +0100 drm: locking&new iterators for connector_list we've went to extreme lengths to make sure connector iterations works in any context, without introducing any additional locking context. This worked, except for a small fumble in the implementation: When we actually race with a concurrent connector unplug event, and our temporary connector reference turns out to be the final one, then everything breaks: We call the connector release function from whatever context we happen to be in, which can be an irq/atomic context. And connector freeing grabs all kinds of locks and stuff. Fix this by creating a specially safe put function for connetor_iter, which (in this rare case) punts the cleanup to a worker. Reported-by: Ben Widawsky <ben(a)bwidawsk.net> Cc: Ben Widawsky <ben(a)bwidawsk.net> Fixes: 613051dac40d ("drm: locking&new iterators for connector_list") Cc: Dave Airlie <airlied(a)gmail.com> Cc: Chris Wilson <chris(a)chris-wilson.co.uk> Cc: Sean Paul <seanpaul(a)chromium.org> Reviewed-by: Dave Airlie <airlied(a)gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter(a)intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171204204818.24745-1-daniel… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/gpu/drm/drm_connector.c | 28 ++++++++++++++++++++++++++-- drivers/gpu/drm/drm_mode_config.c | 2 ++ include/drm/drm_connector.h | 8 ++++++++ 3 files changed, 36 insertions(+), 2 deletions(-) --- a/drivers/gpu/drm/drm_connector.c +++ b/drivers/gpu/drm/drm_connector.c @@ -152,6 +152,16 @@ static void drm_connector_free(struct kr connector->funcs->destroy(connector); } +static void drm_connector_free_work_fn(struct work_struct *work) +{ + struct drm_connector *connector = + container_of(work, struct drm_connector, free_work); + struct drm_device *dev = connector->dev; + + drm_mode_object_unregister(dev, &connector->base); + connector->funcs->destroy(connector); +} + /** * drm_connector_init - Init a preallocated connector * @dev: DRM device @@ -181,6 +191,8 @@ int drm_connector_init(struct drm_device if (ret) return ret; + INIT_WORK(&connector->free_work, drm_connector_free_work_fn); + connector->base.properties = &connector->properties; connector->dev = dev; connector->funcs = funcs; @@ -525,6 +537,18 @@ void drm_connector_list_iter_begin(struc } EXPORT_SYMBOL(drm_connector_list_iter_begin); +/* + * Extra-safe connector put function that works in any context. Should only be + * used from the connector_iter functions, where we never really expect to + * actually release the connector when dropping our final reference. + */ +static void +drm_connector_put_safe(struct drm_connector *conn) +{ + if (refcount_dec_and_test(&conn->base.refcount.refcount)) + schedule_work(&conn->free_work); +} + /** * drm_connector_list_iter_next - return next connector * @iter: connectr_list iterator @@ -557,7 +581,7 @@ drm_connector_list_iter_next(struct drm_ spin_unlock_irqrestore(&config->connector_list_lock, flags); if (old_conn) - drm_connector_put(old_conn); + drm_connector_put_safe(old_conn); return iter->conn; } @@ -576,7 +600,7 @@ void drm_connector_list_iter_end(struct { iter->dev = NULL; if (iter->conn) - drm_connector_put(iter->conn); + drm_connector_put_safe(iter->conn); lock_release(&connector_list_iter_dep_map, 0, _RET_IP_); } EXPORT_SYMBOL(drm_connector_list_iter_end); --- a/drivers/gpu/drm/drm_mode_config.c +++ b/drivers/gpu/drm/drm_mode_config.c @@ -428,6 +428,8 @@ void drm_mode_config_cleanup(struct drm_ drm_connector_put(connector); } drm_connector_list_iter_end(&conn_iter); + /* connector_iter drops references in a work item. */ + flush_scheduled_work(); if (WARN_ON(!list_empty(&dev->mode_config.connector_list))) { drm_connector_list_iter_begin(dev, &conn_iter); drm_for_each_connector_iter(connector, &conn_iter) --- a/include/drm/drm_connector.h +++ b/include/drm/drm_connector.h @@ -905,6 +905,14 @@ struct drm_connector { uint8_t num_h_tile, num_v_tile; uint8_t tile_h_loc, tile_v_loc; uint16_t tile_h_size, tile_v_size; + + /** + * @free_work: + * + * Work used only by &drm_connector_iter to be able to clean up a + * connector from any context. + */ + struct work_struct free_work; }; #define obj_to_connector(x) container_of(x, struct drm_connector, base) Patches currently in stable-queue which might be from daniel.vetter(a)ffwll.ch are queue-4.14/drm-safely-free-connectors-from-connector_iter.patch queue-4.14/drm-i915-fix-vblank-timestamp-frame-counter-jumps-on-gen2.patch

7 years, 1 month

1
0
0 0

[Linux-stable-mirror] Patch "drm/i915: Fix vblank timestamp/frame counter jumps on gen2" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled drm/i915: Fix vblank timestamp/frame counter jumps on gen2 to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: drm-i915-fix-vblank-timestamp-frame-counter-jumps-on-gen2.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From a87e55f89f0b0dc541d89248a8445635936a3858 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= <ville.syrjala(a)linux.intel.com> Date: Wed, 29 Nov 2017 17:37:30 +0200 Subject: drm/i915: Fix vblank timestamp/frame counter jumps on gen2 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Ville Syrjälä <ville.syrjala(a)linux.intel.com> commit a87e55f89f0b0dc541d89248a8445635936a3858 upstream. Previously I was under the impression that the scanline counter reads 0 when the pipe is off. Turns out that's not correct, and instead the scanline counter simply stops when the pipe stops, and it retains it's last value until the pipe starts up again, at which point the scanline counter jumps to vblank start. These jumps can cause the timestamp to jump backwards by one frame. Since we use the timestamps to guesstimage also the frame counter value on gen2, that would cause the frame counter to also jump backwards, which leads to a massice difference from the previous value. The end result is that flips/vblank events don't appear to complete as they're stuck waiting for the frame counter to catch up to that massive difference. Fix the problem properly by actually making sure the scanline counter has started to move before we assume that it's safe to enable vblank processing. v2: Less pointless duplication in the code (Chris) Cc: Daniel Vetter <daniel.vetter(a)ffwll.ch> Cc: Chris Wilson <chris(a)chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris(a)chris-wilson.co.uk> Fixes: b7792d8b54cc ("drm/i915: Wait for pipe to start before sampling vblank timestamps on gen2") Signed-off-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171129153732.3612-1-ville.s… (cherry picked from commit 8fedd64dabc86d0f31a0d1e152be3aa23c323553) Signed-off-by: Joonas Lahtinen <joonas.lahtinen(a)linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/gpu/drm/i915/intel_display.c | 53 +++++++++++++++++++++++------------ 1 file changed, 36 insertions(+), 17 deletions(-) --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -1000,7 +1000,8 @@ enum transcoder intel_pipe_to_cpu_transc return crtc->config->cpu_transcoder; } -static bool pipe_dsl_stopped(struct drm_i915_private *dev_priv, enum pipe pipe) +static bool pipe_scanline_is_moving(struct drm_i915_private *dev_priv, + enum pipe pipe) { i915_reg_t reg = PIPEDSL(pipe); u32 line1, line2; @@ -1015,7 +1016,28 @@ static bool pipe_dsl_stopped(struct drm_ msleep(5); line2 = I915_READ(reg) & line_mask; - return line1 == line2; + return line1 != line2; +} + +static void wait_for_pipe_scanline_moving(struct intel_crtc *crtc, bool state) +{ + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev); + enum pipe pipe = crtc->pipe; + + /* Wait for the display line to settle/start moving */ + if (wait_for(pipe_scanline_is_moving(dev_priv, pipe) == state, 100)) + DRM_ERROR("pipe %c scanline %s wait timed out\n", + pipe_name(pipe), onoff(state)); +} + +static void intel_wait_for_pipe_scanline_stopped(struct intel_crtc *crtc) +{ + wait_for_pipe_scanline_moving(crtc, false); +} + +static void intel_wait_for_pipe_scanline_moving(struct intel_crtc *crtc) +{ + wait_for_pipe_scanline_moving(crtc, true); } /* @@ -1038,7 +1060,6 @@ static void intel_wait_for_pipe_off(stru { struct drm_i915_private *dev_priv = to_i915(crtc->base.dev); enum transcoder cpu_transcoder = crtc->config->cpu_transcoder; - enum pipe pipe = crtc->pipe; if (INTEL_GEN(dev_priv) >= 4) { i915_reg_t reg = PIPECONF(cpu_transcoder); @@ -1049,9 +1070,7 @@ static void intel_wait_for_pipe_off(stru 100)) WARN(1, "pipe_off wait timed out\n"); } else { - /* Wait for the display line to settle */ - if (wait_for(pipe_dsl_stopped(dev_priv, pipe), 100)) - WARN(1, "pipe_off wait timed out\n"); + intel_wait_for_pipe_scanline_stopped(crtc); } } @@ -1944,15 +1963,14 @@ static void intel_enable_pipe(struct int POSTING_READ(reg); /* - * Until the pipe starts DSL will read as 0, which would cause - * an apparent vblank timestamp jump, which messes up also the - * frame count when it's derived from the timestamps. So let's - * wait for the pipe to start properly before we call - * drm_crtc_vblank_on() - */ - if (dev->max_vblank_count == 0 && - wait_for(intel_get_crtc_scanline(crtc) != crtc->scanline_offset, 50)) - DRM_ERROR("pipe %c didn't start\n", pipe_name(pipe)); + * Until the pipe starts PIPEDSL reads will return a stale value, + * which causes an apparent vblank timestamp jump when PIPEDSL + * resets to its proper value. That also messes up the frame count + * when it's derived from the timestamps. So let's wait for the + * pipe to start properly before we call drm_crtc_vblank_on() + */ + if (dev->max_vblank_count == 0) + intel_wait_for_pipe_scanline_moving(crtc); } /** @@ -14682,6 +14700,8 @@ void i830_enable_pipe(struct drm_i915_pr void i830_disable_pipe(struct drm_i915_private *dev_priv, enum pipe pipe) { + struct intel_crtc *crtc = intel_get_crtc_for_pipe(dev_priv, pipe); + DRM_DEBUG_KMS("disabling pipe %c due to force quirk\n", pipe_name(pipe)); @@ -14691,8 +14711,7 @@ void i830_disable_pipe(struct drm_i915_p I915_WRITE(PIPECONF(pipe), 0); POSTING_READ(PIPECONF(pipe)); - if (wait_for(pipe_dsl_stopped(dev_priv, pipe), 100)) - DRM_ERROR("pipe %c off wait timed out\n", pipe_name(pipe)); + intel_wait_for_pipe_scanline_stopped(crtc); I915_WRITE(DPLL(pipe), DPLL_VGA_MODE_DIS); POSTING_READ(DPLL(pipe)); Patches currently in stable-queue which might be from ville.syrjala(a)linux.intel.com are queue-4.14/drm-i915-fix-vblank-timestamp-frame-counter-jumps-on-gen2.patch

7 years, 1 month

1
0
0 0

[Linux-stable-mirror] Patch "drm/exynos: gem: Drop NONCONTIG flag for buffers allocated without IOMMU" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled drm/exynos: gem: Drop NONCONTIG flag for buffers allocated without IOMMU to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: drm-exynos-gem-drop-noncontig-flag-for-buffers-allocated-without-iommu.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 120a264f9c2782682027d931d83dcbd22e01da80 Mon Sep 17 00:00:00 2001 From: Marek Szyprowski <m.szyprowski(a)samsung.com> Date: Wed, 22 Nov 2017 14:14:47 +0100 Subject: drm/exynos: gem: Drop NONCONTIG flag for buffers allocated without IOMMU From: Marek Szyprowski <m.szyprowski(a)samsung.com> commit 120a264f9c2782682027d931d83dcbd22e01da80 upstream. When no IOMMU is available, all GEM buffers allocated by Exynos DRM driver are contiguous, because of the underlying dma_alloc_attrs() function provides only such buffers. In such case it makes no sense to keep BO_NONCONTIG flag for the allocated GEM buffers. This allows to avoid failures for buffer contiguity checks in the subsequent operations on GEM objects. Signed-off-by: Marek Szyprowski <m.szyprowski(a)samsung.com> Signed-off-by: Inki Dae <inki.dae(a)samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/gpu/drm/exynos/exynos_drm_gem.c | 9 +++++++++ 1 file changed, 9 insertions(+) --- a/drivers/gpu/drm/exynos/exynos_drm_gem.c +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c @@ -247,6 +247,15 @@ struct exynos_drm_gem *exynos_drm_gem_cr if (IS_ERR(exynos_gem)) return exynos_gem; + if (!is_drm_iommu_supported(dev) && (flags & EXYNOS_BO_NONCONTIG)) { + /* + * when no IOMMU is available, all allocated buffers are + * contiguous anyway, so drop EXYNOS_BO_NONCONTIG flag + */ + flags &= ~EXYNOS_BO_NONCONTIG; + DRM_WARN("Non-contiguous allocation is not supported without IOMMU, falling back to contiguous buffer\n"); + } + /* set memory type and cache attribute from user side. */ exynos_gem->flags = flags; Patches currently in stable-queue which might be from m.szyprowski(a)samsung.com are queue-4.14/drm-bridge-analogix-dp-fix-runtime-pm-state-in-get_modes-callback.patch queue-4.14/drm-exynos-gem-drop-noncontig-flag-for-buffers-allocated-without-iommu.patch

7 years, 1 month

1
0
0 0

[Linux-stable-mirror] Patch "drm/bridge: analogix dp: Fix runtime PM state in get_modes() callback" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled drm/bridge: analogix dp: Fix runtime PM state in get_modes() callback to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: drm-bridge-analogix-dp-fix-runtime-pm-state-in-get_modes-callback.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 510353a63796d467b41237ab4f136136f68c297d Mon Sep 17 00:00:00 2001 From: Marek Szyprowski <m.szyprowski(a)samsung.com> Date: Tue, 21 Nov 2017 08:49:36 +0100 Subject: drm/bridge: analogix dp: Fix runtime PM state in get_modes() callback From: Marek Szyprowski <m.szyprowski(a)samsung.com> commit 510353a63796d467b41237ab4f136136f68c297d upstream. get_modes() callback might be called asynchronously from the DRM core and it is not synchronized with bridge_enable(), which sets proper runtime PM state of the main DP device. Fix this by calling pm_runtime_get_sync() before calling drm_get_edid(), which in turn calls drm_dp_i2c_xfer() and analogix_dp_transfer() to ensure that main DP device is runtime active when doing any access to its registers. This fixes the following kernel issue on Samsung Exynos5250 Snow board: Unhandled fault: imprecise external abort (0x406) at 0x00000000 pgd = c0004000 [00000000] *pgd=00000000 Internal error: : 406 [#1] PREEMPT SMP ARM Modules linked in: CPU: 0 PID: 62 Comm: kworker/0:2 Not tainted 4.13.0-rc2-00364-g4a97a3da420b #3357 Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) Workqueue: events output_poll_execute task: edc14800 task.stack: edcb2000 PC is at analogix_dp_transfer+0x15c/0x2fc LR is at analogix_dp_transfer+0x134/0x2fc pc : [<c0468538>] lr : [<c0468510>] psr: 60000013 sp : edcb3be8 ip : 0000002a fp : 00000001 r10: 00000000 r9 : edcb3cd8 r8 : edcb3c40 r7 : 00000000 r6 : edd3b380 r5 : edd3b010 r4 : 00000064 r3 : 00000000 r2 : f0ad3000 r1 : edcb3c40 r0 : edd3b010 Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none Control: 10c5387d Table: 4000406a DAC: 00000051 Process kworker/0:2 (pid: 62, stack limit = 0xedcb2210) Stack: (0xedcb3be8 to 0xedcb4000) [<c0468538>] (analogix_dp_transfer) from [<c0424ba4>] (drm_dp_i2c_do_msg+0x8c/0x2b4) [<c0424ba4>] (drm_dp_i2c_do_msg) from [<c0424e64>] (drm_dp_i2c_xfer+0x98/0x214) [<c0424e64>] (drm_dp_i2c_xfer) from [<c057b2d8>] (__i2c_transfer+0x140/0x29c) [<c057b2d8>] (__i2c_transfer) from [<c057b4a4>] (i2c_transfer+0x70/0xe4) [<c057b4a4>] (i2c_transfer) from [<c0441de4>] (drm_do_probe_ddc_edid+0xb4/0x114) [<c0441de4>] (drm_do_probe_ddc_edid) from [<c0441e5c>] (drm_probe_ddc+0x18/0x28) [<c0441e5c>] (drm_probe_ddc) from [<c0445728>] (drm_get_edid+0x124/0x2d4) [<c0445728>] (drm_get_edid) from [<c0465ea0>] (analogix_dp_get_modes+0x90/0x114) [<c0465ea0>] (analogix_dp_get_modes) from [<c0425e8c>] (drm_helper_probe_single_connector_modes+0x198/0x68c) [<c0425e8c>] (drm_helper_probe_single_connector_modes) from [<c04325d4>] (drm_setup_crtcs+0x1b4/0xd18) [<c04325d4>] (drm_setup_crtcs) from [<c04344a8>] (drm_fb_helper_hotplug_event+0x94/0xd0) [<c04344a8>] (drm_fb_helper_hotplug_event) from [<c0425a50>] (drm_kms_helper_hotplug_event+0x24/0x28) [<c0425a50>] (drm_kms_helper_hotplug_event) from [<c04263ec>] (output_poll_execute+0x6c/0x174) [<c04263ec>] (output_poll_execute) from [<c0136f18>] (process_one_work+0x188/0x3fc) [<c0136f18>] (process_one_work) from [<c01371f4>] (worker_thread+0x30/0x4b8) [<c01371f4>] (worker_thread) from [<c013daf8>] (kthread+0x128/0x164) [<c013daf8>] (kthread) from [<c0108510>] (ret_from_fork+0x14/0x24) Code: 0a000002 ea000009 e2544001 0a00004a (e59537c8) ---[ end trace cddc7919c79f7878 ]--- Reported-by: Misha Komarovskiy <zombah(a)gmail.com> Signed-off-by: Marek Szyprowski <m.szyprowski(a)samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Archit Taneja <architt(a)codeaurora.org> Link: https://patchwork.freedesktop.org/patch/msgid/20171121074936.22520-1-m.szyp… --- drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 2 ++ 1 file changed, 2 insertions(+) --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c @@ -946,7 +946,9 @@ static int analogix_dp_get_modes(struct return 0; } + pm_runtime_get_sync(dp->dev); edid = drm_get_edid(connector, &dp->aux.ddc); + pm_runtime_put(dp->dev); if (edid) { drm_mode_connector_update_edid_property(&dp->connector, edid); Patches currently in stable-queue which might be from m.szyprowski(a)samsung.com are queue-4.14/drm-bridge-analogix-dp-fix-runtime-pm-state-in-get_modes-callback.patch queue-4.14/drm-exynos-gem-drop-noncontig-flag-for-buffers-allocated-without-iommu.patch

7 years, 1 month

1
0
0 0

[Linux-stable-mirror] Patch "Drivers: hv: vmbus: Fix a rescind issue" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled Drivers: hv: vmbus: Fix a rescind issue to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: drivers-hv-vmbus-fix-a-rescind-issue.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 7fa32e5ec28b1609abc0b797b58267f725fc3964 Mon Sep 17 00:00:00 2001 From: "K. Y. Srinivasan" <kys(a)microsoft.com> Date: Tue, 14 Nov 2017 06:53:33 -0700 Subject: Drivers: hv: vmbus: Fix a rescind issue From: K. Y. Srinivasan <kys(a)microsoft.com> commit 7fa32e5ec28b1609abc0b797b58267f725fc3964 upstream. The current rescind processing code will not correctly handle the case where the host immediately rescinds a channel that has been offerred. In this case, we could be blocked in the open call and since the channel is rescinded, the host will not respond and we could be blocked forever in the vmbus open call.i Fix this problem. Signed-off-by: K. Y. Srinivasan <kys(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/hv/channel.c | 10 ++++++++-- drivers/hv/channel_mgmt.c | 7 ++++--- include/linux/hyperv.h | 1 + 3 files changed, 13 insertions(+), 5 deletions(-) --- a/drivers/hv/channel.c +++ b/drivers/hv/channel.c @@ -640,22 +640,28 @@ void vmbus_close(struct vmbus_channel *c */ return; } - mutex_lock(&vmbus_connection.channel_mutex); /* * Close all the sub-channels first and then close the * primary channel. */ list_for_each_safe(cur, tmp, &channel->sc_list) { cur_channel = list_entry(cur, struct vmbus_channel, sc_list); - vmbus_close_internal(cur_channel); if (cur_channel->rescind) { + wait_for_completion(&cur_channel->rescind_event); + mutex_lock(&vmbus_connection.channel_mutex); + vmbus_close_internal(cur_channel); hv_process_channel_removal( cur_channel->offermsg.child_relid); + } else { + mutex_lock(&vmbus_connection.channel_mutex); + vmbus_close_internal(cur_channel); } + mutex_unlock(&vmbus_connection.channel_mutex); } /* * Now close the primary. */ + mutex_lock(&vmbus_connection.channel_mutex); vmbus_close_internal(channel); mutex_unlock(&vmbus_connection.channel_mutex); } --- a/drivers/hv/channel_mgmt.c +++ b/drivers/hv/channel_mgmt.c @@ -333,6 +333,7 @@ static struct vmbus_channel *alloc_chann return NULL; spin_lock_init(&channel->lock); + init_completion(&channel->rescind_event); INIT_LIST_HEAD(&channel->sc_list); INIT_LIST_HEAD(&channel->percpu_list); @@ -883,6 +884,7 @@ static void vmbus_onoffer_rescind(struct /* * Now wait for offer handling to complete. */ + vmbus_rescind_cleanup(channel); while (READ_ONCE(channel->probe_done) == false) { /* * We wait here until any channel offer is currently @@ -898,7 +900,6 @@ static void vmbus_onoffer_rescind(struct if (channel->device_obj) { if (channel->chn_rescind_callback) { channel->chn_rescind_callback(channel); - vmbus_rescind_cleanup(channel); return; } /* @@ -907,7 +908,6 @@ static void vmbus_onoffer_rescind(struct */ dev = get_device(&channel->device_obj->device); if (dev) { - vmbus_rescind_cleanup(channel); vmbus_device_unregister(channel->device_obj); put_device(dev); } @@ -921,13 +921,14 @@ static void vmbus_onoffer_rescind(struct * 2. Then close the primary channel. */ mutex_lock(&vmbus_connection.channel_mutex); - vmbus_rescind_cleanup(channel); if (channel->state == CHANNEL_OPEN_STATE) { /* * The channel is currently not open; * it is safe for us to cleanup the channel. */ hv_process_channel_removal(rescind->child_relid); + } else { + complete(&channel->rescind_event); } mutex_unlock(&vmbus_connection.channel_mutex); } --- a/include/linux/hyperv.h +++ b/include/linux/hyperv.h @@ -708,6 +708,7 @@ struct vmbus_channel { u8 monitor_bit; bool rescind; /* got rescind msg */ + struct completion rescind_event; u32 ringbuffer_gpadlhandle; Patches currently in stable-queue which might be from kys(a)microsoft.com are queue-4.14/hv-kvp-avoid-reading-past-allocated-blocks-from-kvp-file.patch queue-4.14/drivers-hv-vmbus-fix-a-rescind-issue.patch

7 years, 1 month

1
0
0 0

[Linux-stable-mirror] Patch "bus: arm-ccn: Fix use of smp_processor_id() in preemptible context" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled bus: arm-ccn: Fix use of smp_processor_id() in preemptible context to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: bus-arm-ccn-fix-use-of-smp_processor_id-in-preemptible-context.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From b18c2b9487d8e797fc0a757e57ac3645348c5fba Mon Sep 17 00:00:00 2001 From: Marc Zyngier <marc.zyngier(a)arm.com> Date: Tue, 3 Oct 2017 18:14:12 +0100 Subject: bus: arm-ccn: Fix use of smp_processor_id() in preemptible context From: Marc Zyngier <marc.zyngier(a)arm.com> commit b18c2b9487d8e797fc0a757e57ac3645348c5fba upstream. Booting a DEBUG_PREEMPT enabled kernel on a CCN-based system results in the following splat: [...] arm-ccn e8000000.ccn: No access to interrupts, using timer. BUG: using smp_processor_id() in preemptible [00000000] code: swapper/0/1 caller is debug_smp_processor_id+0x1c/0x28 CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.13.0 #6111 Hardware name: AMD Seattle/Seattle, BIOS 17:08:23 Jun 26 2017 Call trace: [<ffff000008089e78>] dump_backtrace+0x0/0x278 [<ffff00000808a22c>] show_stack+0x24/0x30 [<ffff000008bc3bc4>] dump_stack+0x8c/0xb0 [<ffff00000852b534>] check_preemption_disabled+0xfc/0x100 [<ffff00000852b554>] debug_smp_processor_id+0x1c/0x28 [<ffff000008551bd8>] arm_ccn_probe+0x358/0x4f0 [...] as we use smp_processor_id() in the wrong context. Turn this into a get_cpu()/put_cpu() that extends over the CPU hotplug registration, making sure that we don't race against a CPU down operation. Signed-off-by: Marc Zyngier <marc.zyngier(a)arm.com> Acked-by: Mark Rutland <mark.rutland(a)arm.com> Signed-off-by: Pawel Moll <pawel.moll(a)arm.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/bus/arm-ccn.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) --- a/drivers/bus/arm-ccn.c +++ b/drivers/bus/arm-ccn.c @@ -1301,7 +1301,7 @@ static int arm_ccn_pmu_init(struct arm_c } /* Pick one CPU which we will use to collect data from CCN... */ - cpumask_set_cpu(smp_processor_id(), &ccn->dt.cpu); + cpumask_set_cpu(get_cpu(), &ccn->dt.cpu); /* Also make sure that the overflow interrupt is handled by this CPU */ if (ccn->irq) { @@ -1318,10 +1318,12 @@ static int arm_ccn_pmu_init(struct arm_c cpuhp_state_add_instance_nocalls(CPUHP_AP_PERF_ARM_CCN_ONLINE, &ccn->dt.node); + put_cpu(); return 0; error_pmu_register: error_set_affinity: + put_cpu(); error_choose_name: ida_simple_remove(&arm_ccn_pmu_ida, ccn->dt.id); for (i = 0; i < ccn->num_xps; i++) Patches currently in stable-queue which might be from marc.zyngier(a)arm.com are queue-4.14/arm-kvm-fix-vttbr_baddr_mask-bug_on-off-by-one.patch queue-4.14/kvm-arm-arm64-vgic-its-check-result-of-allocation-before-use.patch queue-4.14/kvm-arm-arm64-vgic-preserve-the-revious-read-from-the-pending-table.patch queue-4.14/kvm-arm-arm64-vgic-irqfd-fix-msi-entry-allocation.patch queue-4.14/bus-arm-cci-fix-use-of-smp_processor_id-in-preemptible-context.patch queue-4.14/arm64-kvm-fix-vttbr_baddr_mask-bug_on-off-by-one.patch queue-4.14/bus-arm-ccn-fix-use-of-smp_processor_id-in-preemptible-context.patch

7 years, 1 month

1
0
0 0

[Linux-stable-mirror] Patch "bus: arm-ccn: fix module unloading Error: Removing state 147 which has instances left." has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled bus: arm-ccn: fix module unloading Error: Removing state 147 which has instances left. to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: bus-arm-ccn-fix-module-unloading-error-removing-state-147-which-has-instances-left.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From b69f63ebf553504739cc8534cbed31bd530c6f0b Mon Sep 17 00:00:00 2001 From: Kim Phillips <kim.phillips(a)arm.com> Date: Wed, 11 Oct 2017 22:33:24 +0100 Subject: bus: arm-ccn: fix module unloading Error: Removing state 147 which has instances left. From: Kim Phillips <kim.phillips(a)arm.com> commit b69f63ebf553504739cc8534cbed31bd530c6f0b upstream. Unregistering the driver before calling cpuhp_remove_multi_state() removes any remaining hotplug cpu instances so __cpuhp_remove_state_cpuslocked() doesn't emit this warning: [ 268.748362] Error: Removing state 147 which has instances left. [ 268.748373] ------------[ cut here ]------------ [ 268.748386] WARNING: CPU: 2 PID: 5476 at kernel/cpu.c:1734 __cpuhp_remove_state_cpuslocked+0x454/0x4f0 [ 268.748389] Modules linked in: arm_ccn(-) [last unloaded: arm_ccn] [ 268.748403] CPU: 2 PID: 5476 Comm: rmmod Tainted: G W 4.14.0-rc4+ #3 [ 268.748406] Hardware name: AMD Seattle/Seattle, BIOS 10:18:39 Dec 8 2016 [ 268.748410] task: ffff8001a18ca000 task.stack: ffff80019c120000 [ 268.748416] PC is at __cpuhp_remove_state_cpuslocked+0x454/0x4f0 [ 268.748421] LR is at __cpuhp_remove_state_cpuslocked+0x448/0x4f0 [ 268.748425] pc : [<ffff2000081729ec>] lr : [<ffff2000081729e0>] pstate: 60000145 [ 268.748427] sp : ffff80019c127d30 [ 268.748430] x29: ffff80019c127d30 x28: ffff8001a18ca000 [ 268.748437] x27: ffff20000c2cb000 x26: 1fffe4000042d490 [ 268.748443] x25: ffff20000216a480 x24: 0000000000000000 [ 268.748449] x23: ffff20000b08e000 x22: 0000000000000001 [ 268.748455] x21: 0000000000000093 x20: 00000000000016f8 [ 268.748460] x19: ffff20000c2cbb80 x18: 0000ffffb5fe7c58 [ 268.748466] x17: 00000000004402d0 x16: 1fffe40001864f01 [ 268.748472] x15: ffff20000c4bf8b0 x14: 0000000000000000 [ 268.748477] x13: 0000000000007032 x12: ffff20000829ae48 [ 268.748483] x11: ffff20000c4bf000 x10: 0000000000000004 [ 268.748488] x9 : 0000000000006fbc x8 : ffff20000c318a40 [ 268.748494] x7 : 0000000000000000 x6 : ffff040001864f02 [ 268.748500] x5 : 0000000000000000 x4 : 0000000000000000 [ 268.748505] x3 : 0000000000000007 x2 : dfff200000000000 [ 268.748510] x1 : 000000000000ad3d x0 : 00000000000001f0 [ 268.748516] Call trace: [ 268.748521] Exception stack(0xffff80019c127bf0 to 0xffff80019c127d30) [ 268.748526] 7be0: 00000000000001f0 000000000000ad3d [ 268.748531] 7c00: dfff200000000000 0000000000000007 0000000000000000 0000000000000000 [ 268.748535] 7c20: ffff040001864f02 0000000000000000 ffff20000c318a40 0000000000006fbc [ 268.748539] 7c40: 0000000000000004 ffff20000c4bf000 ffff20000829ae48 0000000000007032 [ 268.748544] 7c60: 0000000000000000 ffff20000c4bf8b0 1fffe40001864f01 00000000004402d0 [ 268.748548] 7c80: 0000ffffb5fe7c58 ffff20000c2cbb80 00000000000016f8 0000000000000093 [ 268.748553] 7ca0: 0000000000000001 ffff20000b08e000 0000000000000000 ffff20000216a480 [ 268.748557] 7cc0: 1fffe4000042d490 ffff20000c2cb000 ffff8001a18ca000 ffff80019c127d30 [ 268.748562] 7ce0: ffff2000081729e0 ffff80019c127d30 ffff2000081729ec 0000000060000145 [ 268.748566] 7d00: 00000000000001f0 0000000000000000 0001000000000000 0000000000000000 [ 268.748569] 7d20: ffff80019c127d30 ffff2000081729ec [ 268.748575] [<ffff2000081729ec>] __cpuhp_remove_state_cpuslocked+0x454/0x4f0 [ 268.748580] [<ffff200008172adc>] __cpuhp_remove_state+0x54/0x80 [ 268.748597] [<ffff20000215dd84>] arm_ccn_exit+0x2c/0x70 [arm_ccn] [ 268.748604] [<ffff20000834cfbc>] SyS_delete_module+0x5a4/0x708 [ 268.748607] Exception stack(0xffff80019c127ec0 to 0xffff80019c128000) [ 268.748612] 7ec0: 0000000019bb7258 0000000000000800 ba64d0fb3d26a800 00000000000000da [ 268.748616] 7ee0: 0000ffffb6144e28 0000ffffcd95b409 fefefefefefefeff 7f7f7f7f7f7f7f7f [ 268.748621] 7f00: 000000000000006a 1999999999999999 0000ffffb6179000 0000000000bbcc6d [ 268.748625] 7f20: 0000ffffb6176b98 0000ffffcd95c2d0 0000ffffb5fe7b58 0000ffffb6163000 [ 268.748630] 7f40: 0000ffffb60ad3e0 00000000004402d0 0000ffffb5fe7c58 0000000019bb71f0 [ 268.748634] 7f60: 0000ffffcd95c740 0000000000000000 0000000019bb71f0 0000000000416700 [ 268.748639] 7f80: 0000000000000000 00000000004402e8 0000000019bb6010 0000ffffcd95c748 [ 268.748643] 7fa0: 0000000000000000 0000ffffcd95c460 00000000004113a8 0000ffffcd95c460 [ 268.748648] 7fc0: 0000ffffb60ad3e8 0000000080000000 0000000019bb7258 000000000000006a [ 268.748652] 7fe0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 [ 268.748657] [<ffff200008084f9c>] __sys_trace_return+0x0/0x4 [ 268.748661] ---[ end trace a996d358dcaa7f9c ]--- Fixes: 8df038725ad5 ("bus/arm-ccn: Use cpu-hp's multi instance support instead custom list") Signed-off-by: Kim Phillips <kim.phillips(a)arm.com> Acked-by: Sebastian Andrzej Siewior <bigeasy(a)linutronix.de> Signed-off-by: Pawel Moll <pawel.moll(a)arm.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/bus/arm-ccn.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/bus/arm-ccn.c +++ b/drivers/bus/arm-ccn.c @@ -1587,8 +1587,8 @@ static int __init arm_ccn_init(void) static void __exit arm_ccn_exit(void) { - cpuhp_remove_multi_state(CPUHP_AP_PERF_ARM_CCN_ONLINE); platform_driver_unregister(&arm_ccn_driver); + cpuhp_remove_multi_state(CPUHP_AP_PERF_ARM_CCN_ONLINE); } module_init(arm_ccn_init); Patches currently in stable-queue which might be from kim.phillips(a)arm.com are queue-4.14/bus-arm-ccn-fix-module-unloading-error-removing-state-147-which-has-instances-left.patch

7 years, 1 month

1
0
0 0

[Linux-stable-mirror] Patch "bus: arm-ccn: Check memory allocation failure" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled bus: arm-ccn: Check memory allocation failure to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: bus-arm-ccn-check-memory-allocation-failure.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 24771179c5c138f0ea3ef88b7972979f62f2d5db Mon Sep 17 00:00:00 2001 From: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr> Date: Sun, 27 Aug 2017 11:06:50 +0100 Subject: bus: arm-ccn: Check memory allocation failure From: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr> commit 24771179c5c138f0ea3ef88b7972979f62f2d5db upstream. Check memory allocation failures and return -ENOMEM in such cases This avoids a potential NULL pointer dereference. Signed-off-by: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr> Acked-by: Scott Branden <scott.branden(a)broadcom.com> Signed-off-by: Pawel Moll <pawel.moll(a)arm.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/bus/arm-ccn.c | 5 +++++ 1 file changed, 5 insertions(+) --- a/drivers/bus/arm-ccn.c +++ b/drivers/bus/arm-ccn.c @@ -1271,6 +1271,10 @@ static int arm_ccn_pmu_init(struct arm_c int len = snprintf(NULL, 0, "ccn_%d", ccn->dt.id); name = devm_kzalloc(ccn->dev, len + 1, GFP_KERNEL); + if (!name) { + err = -ENOMEM; + goto error_choose_name; + } snprintf(name, len + 1, "ccn_%d", ccn->dt.id); } @@ -1318,6 +1322,7 @@ static int arm_ccn_pmu_init(struct arm_c error_pmu_register: error_set_affinity: +error_choose_name: ida_simple_remove(&arm_ccn_pmu_ida, ccn->dt.id); for (i = 0; i < ccn->num_xps; i++) writel(0, ccn->xp[i].base + CCN_XP_DT_CONTROL); Patches currently in stable-queue which might be from christophe.jaillet(a)wanadoo.fr are queue-4.14/bus-arm-ccn-check-memory-allocation-failure.patch

7 years, 1 month

1
0
0 0

[Linux-stable-mirror] Patch "bus: arm-cci: Fix use of smp_processor_id() in preemptible context" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled bus: arm-cci: Fix use of smp_processor_id() in preemptible context to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: bus-arm-cci-fix-use-of-smp_processor_id-in-preemptible-context.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 4608af8aa53e7f3922ddee695d023b7bcd5cb35b Mon Sep 17 00:00:00 2001 From: Marc Zyngier <marc.zyngier(a)arm.com> Date: Tue, 3 Oct 2017 18:14:13 +0100 Subject: bus: arm-cci: Fix use of smp_processor_id() in preemptible context From: Marc Zyngier <marc.zyngier(a)arm.com> commit 4608af8aa53e7f3922ddee695d023b7bcd5cb35b upstream. The ARM CCI driver seem to be using smp_processor_id() in a preemptible context, which is likely to make a DEBUG_PREMPT kernel scream at boot time. Turn this into a get_cpu()/put_cpu() that extends over the CPU hotplug registration, making sure that we don't race against a CPU down operation. Signed-off-by: Marc Zyngier <marc.zyngier(a)arm.com> Acked-by: Mark Rutland <mark.rutland(a)arm.com> Signed-off-by: Pawel Moll <pawel.moll(a)arm.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/bus/arm-cci.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) --- a/drivers/bus/arm-cci.c +++ b/drivers/bus/arm-cci.c @@ -1755,14 +1755,17 @@ static int cci_pmu_probe(struct platform raw_spin_lock_init(&cci_pmu->hw_events.pmu_lock); mutex_init(&cci_pmu->reserve_mutex); atomic_set(&cci_pmu->active_events, 0); - cpumask_set_cpu(smp_processor_id(), &cci_pmu->cpus); + cpumask_set_cpu(get_cpu(), &cci_pmu->cpus); ret = cci_pmu_init(cci_pmu, pdev); - if (ret) + if (ret) { + put_cpu(); return ret; + } cpuhp_state_add_instance_nocalls(CPUHP_AP_PERF_ARM_CCI_ONLINE, &cci_pmu->node); + put_cpu(); pr_info("ARM %s PMU driver probed", cci_pmu->model->name); return 0; } Patches currently in stable-queue which might be from marc.zyngier(a)arm.com are queue-4.14/arm-kvm-fix-vttbr_baddr_mask-bug_on-off-by-one.patch queue-4.14/kvm-arm-arm64-vgic-its-check-result-of-allocation-before-use.patch queue-4.14/kvm-arm-arm64-vgic-preserve-the-revious-read-from-the-pending-table.patch queue-4.14/kvm-arm-arm64-vgic-irqfd-fix-msi-entry-allocation.patch queue-4.14/bus-arm-cci-fix-use-of-smp_processor_id-in-preemptible-context.patch queue-4.14/arm64-kvm-fix-vttbr_baddr_mask-bug_on-off-by-one.patch queue-4.14/bus-arm-ccn-fix-use-of-smp_processor_id-in-preemptible-context.patch

7 years, 1 month

1
0
0 0

[Linux-stable-mirror] Patch "btrfs: handle errors while updating refcounts in update_ref_for_cow" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled btrfs: handle errors while updating refcounts in update_ref_for_cow to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: btrfs-handle-errors-while-updating-refcounts-in-update_ref_for_cow.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 692826b2738101549f032a761a9191636e83be4e Mon Sep 17 00:00:00 2001 From: Jeff Mahoney <jeffm(a)suse.com> Date: Tue, 21 Nov 2017 13:58:49 -0500 Subject: btrfs: handle errors while updating refcounts in update_ref_for_cow From: Jeff Mahoney <jeffm(a)suse.com> commit 692826b2738101549f032a761a9191636e83be4e upstream. Since commit fb235dc06fa (btrfs: qgroup: Move half of the qgroup accounting time out of commit trans) the assumption that btrfs_add_delayed_{data,tree}_ref can only return 0 or -ENOMEM has been false. The qgroup operations call into btrfs_search_slot and friends and can now return the full spectrum of error codes. Fortunately, the fix here is easy since update_ref_for_cow failing is already handled so we just need to bail early with the error code. Fixes: fb235dc06fa (btrfs: qgroup: Move half of the qgroup accounting ...) Signed-off-by: Jeff Mahoney <jeffm(a)suse.com> Reviewed-by: Edmund Nadolski <enadolski(a)suse.com> Reviewed-by: Qu Wenruo <wqu(a)suse.com> Signed-off-by: David Sterba <dsterba(a)suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/btrfs/ctree.c | 18 ++++++++++++------ 1 file changed, 12 insertions(+), 6 deletions(-) --- a/fs/btrfs/ctree.c +++ b/fs/btrfs/ctree.c @@ -1032,14 +1032,17 @@ static noinline int update_ref_for_cow(s root->root_key.objectid == BTRFS_TREE_RELOC_OBJECTID) && !(flags & BTRFS_BLOCK_FLAG_FULL_BACKREF)) { ret = btrfs_inc_ref(trans, root, buf, 1); - BUG_ON(ret); /* -ENOMEM */ + if (ret) + return ret; if (root->root_key.objectid == BTRFS_TREE_RELOC_OBJECTID) { ret = btrfs_dec_ref(trans, root, buf, 0); - BUG_ON(ret); /* -ENOMEM */ + if (ret) + return ret; ret = btrfs_inc_ref(trans, root, cow, 1); - BUG_ON(ret); /* -ENOMEM */ + if (ret) + return ret; } new_flags |= BTRFS_BLOCK_FLAG_FULL_BACKREF; } else { @@ -1049,7 +1052,8 @@ static noinline int update_ref_for_cow(s ret = btrfs_inc_ref(trans, root, cow, 1); else ret = btrfs_inc_ref(trans, root, cow, 0); - BUG_ON(ret); /* -ENOMEM */ + if (ret) + return ret; } if (new_flags != 0) { int level = btrfs_header_level(buf); @@ -1068,9 +1072,11 @@ static noinline int update_ref_for_cow(s ret = btrfs_inc_ref(trans, root, cow, 1); else ret = btrfs_inc_ref(trans, root, cow, 0); - BUG_ON(ret); /* -ENOMEM */ + if (ret) + return ret; ret = btrfs_dec_ref(trans, root, buf, 1); - BUG_ON(ret); /* -ENOMEM */ + if (ret) + return ret; } clean_tree_block(fs_info, buf); *last_ref = 1; Patches currently in stable-queue which might be from jeffm(a)suse.com are queue-4.14/btrfs-fix-missing-error-return-in-btrfs_drop_snapshot.patch queue-4.14/btrfs-handle-errors-while-updating-refcounts-in-update_ref_for_cow.patch

7 years, 1 month

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror December 2017