From 58f90988b6589ddb13a296240054a6e81a5d2d4c Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Tue, 3 Jun 2014 23:16:48 -0700 Subject: [PATCH] 3.14-stable patches added patches: drm-i915-disable-self-refresh-for-untiled-fbs-on-i915gm.patch drm-i915-fix-unsafe-loop-iteration-over-vma-whilst-unbinding-them.patch drm-i915-move-power-domain-init-earlier-during-system-resume.patch drm-i915-quirk-invert-brightness-for-acer-aspire-5336.patch iscsi-target-change-bug_on-to-reject-in-iscsit_process_nop_out.patch target-allow-non-supporting-backends-to-set-pi_prot_type-to-0.patch target-don-t-allow-setting-wc-emulation-if-device-doesn-t-support.patch target-fix-memory-leak-on-xcopy.patch target-iser-fix-iscsit_accept_np-and-rdma_cm-racy-flow.patch target-iser-fix-wrong-connection-requests-list-addition.patch --- ...lf-refresh-for-untiled-fbs-on-i915gm.patch | 64 +++++ ...ation-over-vma-whilst-unbinding-them.patch | 58 +++++ ...in-init-earlier-during-system-resume.patch | 223 ++++++++++++++++++ ...vert-brightness-for-acer-aspire-5336.patch | 58 +++++ ...-to-reject-in-iscsit_process_nop_out.patch | 45 ++++ queue-3.14/series | 10 + ...ng-backends-to-set-pi_prot_type-to-0.patch | 37 +++ ...-emulation-if-device-doesn-t-support.patch | 40 ++++ .../target-fix-memory-leak-on-xcopy.patch | 51 ++++ ...csit_accept_np-and-rdma_cm-racy-flow.patch | 112 +++++++++ ...ng-connection-requests-list-addition.patch | 31 +++ 11 files changed, 729 insertions(+) create mode 100644 queue-3.14/drm-i915-disable-self-refresh-for-untiled-fbs-on-i915gm.patch create mode 100644 queue-3.14/drm-i915-fix-unsafe-loop-iteration-over-vma-whilst-unbinding-them.patch create mode 100644 queue-3.14/drm-i915-move-power-domain-init-earlier-during-system-resume.patch create mode 100644 queue-3.14/drm-i915-quirk-invert-brightness-for-acer-aspire-5336.patch create mode 100644 queue-3.14/iscsi-target-change-bug_on-to-reject-in-iscsit_process_nop_out.patch create mode 100644 queue-3.14/target-allow-non-supporting-backends-to-set-pi_prot_type-to-0.patch create mode 100644 queue-3.14/target-don-t-allow-setting-wc-emulation-if-device-doesn-t-support.patch create mode 100644 queue-3.14/target-fix-memory-leak-on-xcopy.patch create mode 100644 queue-3.14/target-iser-fix-iscsit_accept_np-and-rdma_cm-racy-flow.patch create mode 100644 queue-3.14/target-iser-fix-wrong-connection-requests-list-addition.patch diff --git a/queue-3.14/drm-i915-disable-self-refresh-for-untiled-fbs-on-i915gm.patch b/queue-3.14/drm-i915-disable-self-refresh-for-untiled-fbs-on-i915gm.patch new file mode 100644 index 00000000000..1f478be0c22 --- /dev/null +++ b/queue-3.14/drm-i915-disable-self-refresh-for-untiled-fbs-on-i915gm.patch @@ -0,0 +1,64 @@ +From daniel.vetter@ffwll.ch Tue Jun 3 23:12:52 2014 +From: Daniel Vetter +Date: Wed, 21 May 2014 11:07:22 +0200 +Subject: drm/i915: Disable self-refresh for untiled fbs on i915gm +To: stable@vger.kernel.org +Cc: Intel Graphics Development , Daniel Vetter , Ville Syrjälä , Chris Wilson , Krzysztof Mazur , Jani Nikula +Message-ID: <1400663245-15601-2-git-send-email-daniel.vetter@ffwll.ch> + +From: Daniel Vetter + +This is commit 2ab1bc9df01dbc19b55b2271100db7 upstream. + +Apparently it doesn't work. X-tiled self-refresh works flawlessly +otoh. Apparently X still works correctly with linear framebuffers, so +might just be an issue with the initial modeset. It's unclear whether +this just borked wm setup from our side or a hw restriction, but just +disabling gets things going. + +Note that this regression was only brought to light with + +commit 3f2dc5ac05714711fc14f2bf0ee5e42d5c08c581 +Author: Ville Syrjälä +Date: Fri Jan 10 14:06:47 2014 +0200 + + drm/i915: Fix 915GM self-refresh enable/disable + +before that self-refresh for i915GM didn't work at all. + +Kudos to Ville for spotting a little bug in the original patch I've +attached to the bug. + +Cc: Ville Syrjälä +Cc: Chris Wilson +Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76103 +Tested-by: Krzysztof Mazur +Cc: Krzysztof Mazur +Reviewed-by: Ville Syrjälä +Signed-off-by: Daniel Vetter +[Jani: rebase on top of drm-next with primary plane support.] +Signed-off-by: Jani Nikula +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/i915/intel_pm.c | 10 ++++++++++ + 1 file changed, 10 insertions(+) + +--- a/drivers/gpu/drm/i915/intel_pm.c ++++ b/drivers/gpu/drm/i915/intel_pm.c +@@ -1539,6 +1539,16 @@ static void i9xx_update_wm(struct drm_cr + + DRM_DEBUG_KMS("FIFO watermarks - A: %d, B: %d\n", planea_wm, planeb_wm); + ++ if (IS_I915GM(dev) && enabled) { ++ struct intel_framebuffer *fb; ++ ++ fb = to_intel_framebuffer(enabled->fb); ++ ++ /* self-refresh seems busted with untiled */ ++ if (fb->obj->tiling_mode == I915_TILING_NONE) ++ enabled = NULL; ++ } ++ + /* + * Overlay gets an aggressive default since video jitter is bad. + */ diff --git a/queue-3.14/drm-i915-fix-unsafe-loop-iteration-over-vma-whilst-unbinding-them.patch b/queue-3.14/drm-i915-fix-unsafe-loop-iteration-over-vma-whilst-unbinding-them.patch new file mode 100644 index 00000000000..06e75d06c9c --- /dev/null +++ b/queue-3.14/drm-i915-fix-unsafe-loop-iteration-over-vma-whilst-unbinding-them.patch @@ -0,0 +1,58 @@ +From daniel.vetter@ffwll.ch Tue Jun 3 23:13:34 2014 +From: Daniel Vetter +Date: Wed, 21 May 2014 11:07:24 +0200 +Subject: drm/i915: Fix unsafe loop iteration over vma whilst unbinding them +To: stable@vger.kernel.org +Cc: Intel Graphics Development , Chris Wilson , Ben Widawsky , Daniel Vetter +Message-ID: <1400663245-15601-4-git-send-email-daniel.vetter@ffwll.ch> + + +From: Chris Wilson + +This is commit df6f783a4ef6790780a67c491897ac upstream. + +On non-LLC platforms, when changing the cache level of an object, we may +need to unbind it so that prefetching across page boundaries does not +cross into a different memory domain. This requires us to unbind +conflicting vma, but we did so iterating over the objects vma in an +unsafe manner (as the list was being modified as we iterated). + +The regression was introduced in +commit 3089c6f239d7d2c4cb2dd5c353e8984cf79af1d7 +Author: Ben Widawsky +Date: Wed Jul 31 17:00:03 2013 -0700 + + drm/i915: make caching operate on all address spaces +apparently as far back as v3.12-rc1, but it has only just begun to +trigger real world bug reports. + +Reported-and-tested-by: Nikolay Martynov +Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76384 +Signed-off-by: Chris Wilson +Cc: Ben Widawsky +Signed-off-by: Daniel Vetter +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/i915/i915_gem.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/drivers/gpu/drm/i915/i915_gem.c ++++ b/drivers/gpu/drm/i915/i915_gem.c +@@ -3529,7 +3529,7 @@ int i915_gem_object_set_cache_level(stru + { + struct drm_device *dev = obj->base.dev; + drm_i915_private_t *dev_priv = dev->dev_private; +- struct i915_vma *vma; ++ struct i915_vma *vma, *next; + int ret; + + if (obj->cache_level == cache_level) +@@ -3540,7 +3540,7 @@ int i915_gem_object_set_cache_level(stru + return -EBUSY; + } + +- list_for_each_entry(vma, &obj->vma_list, vma_link) { ++ list_for_each_entry_safe(vma, next, &obj->vma_list, vma_link) { + if (!i915_gem_valid_gtt_space(dev, &vma->node, cache_level)) { + ret = i915_vma_unbind(vma); + if (ret) diff --git a/queue-3.14/drm-i915-move-power-domain-init-earlier-during-system-resume.patch b/queue-3.14/drm-i915-move-power-domain-init-earlier-during-system-resume.patch new file mode 100644 index 00000000000..9baff823082 --- /dev/null +++ b/queue-3.14/drm-i915-move-power-domain-init-earlier-during-system-resume.patch @@ -0,0 +1,223 @@ +From daniel.vetter@ffwll.ch Tue Jun 3 23:13:18 2014 +From: Daniel Vetter +Date: Wed, 21 May 2014 11:07:23 +0200 +Subject: drm/i915: move power domain init earlier during system resume +To: stable@vger.kernel.org +Cc: Intel Graphics Development , Imre Deak , Daniel Vetter +Message-ID: <1400663245-15601-3-git-send-email-daniel.vetter@ffwll.ch> + + +From: Imre Deak + +This is commit 76c4b250080fff6e4befaa36199424 upstream. + +During resume the intel hda audio driver depends on the i915 driver +reinitializing the audio power domain. Since the order of calling the +i915 resume handler wrt. that of the audio driver is not guaranteed, +move the power domain reinitialization step to the resume_early +handler. This is guaranteed to run before the resume handler of any +other driver. + +The power domain initialization in turn requires us to enable the i915 +pci device first, so move that part earlier too. + +Accordingly disabling of the i915 pci device should happen after the +audio suspend handler ran. So move the disabling later from the i915 +resume handler to the resume_late handler. + +v2: +- move intel_uncore_sanitize/early_sanitize earlier too, so they don't + get reordered wrt. intel_power_domains_init_hw() + +Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76152 +Signed-off-by: Imre Deak +Reviewed-by: Takashi Iwai +[danvet: Add cc: stable and loud comments that this is just a hack.] +[danvet: Fix "Should it be static?" sparse warning reported by Wu +Fengguang's kbuilder.] +Signed-off-by: Daniel Vetter +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/i915/i915_drv.c | 90 +++++++++++++++++++++++++++++++++------- + 1 file changed, 75 insertions(+), 15 deletions(-) + +--- a/drivers/gpu/drm/i915/i915_drv.c ++++ b/drivers/gpu/drm/i915/i915_drv.c +@@ -614,15 +614,20 @@ static void intel_resume_hotplug(struct + drm_helper_hpd_irq_event(dev); + } + ++static int i915_drm_thaw_early(struct drm_device *dev) ++{ ++ intel_uncore_early_sanitize(dev); ++ intel_uncore_sanitize(dev); ++ intel_power_domains_init_hw(dev); ++ ++ return 0; ++} ++ + static int __i915_drm_thaw(struct drm_device *dev, bool restore_gtt_mappings) + { + struct drm_i915_private *dev_priv = dev->dev_private; + int error = 0; + +- intel_uncore_early_sanitize(dev); +- +- intel_uncore_sanitize(dev); +- + if (drm_core_check_feature(dev, DRIVER_MODESET) && + restore_gtt_mappings) { + mutex_lock(&dev->struct_mutex); +@@ -630,8 +635,6 @@ static int __i915_drm_thaw(struct drm_de + mutex_unlock(&dev->struct_mutex); + } + +- intel_power_domains_init_hw(dev); +- + i915_restore_state(dev); + intel_opregion_setup(dev); + +@@ -700,19 +703,33 @@ static int i915_drm_thaw(struct drm_devi + return __i915_drm_thaw(dev, true); + } + +-int i915_resume(struct drm_device *dev) ++static int i915_resume_early(struct drm_device *dev) + { +- struct drm_i915_private *dev_priv = dev->dev_private; +- int ret; +- + if (dev->switch_power_state == DRM_SWITCH_POWER_OFF) + return 0; + ++ /* ++ * We have a resume ordering issue with the snd-hda driver also ++ * requiring our device to be power up. Due to the lack of a ++ * parent/child relationship we currently solve this with an early ++ * resume hook. ++ * ++ * FIXME: This should be solved with a special hdmi sink device or ++ * similar so that power domains can be employed. ++ */ + if (pci_enable_device(dev->pdev)) + return -EIO; + + pci_set_master(dev->pdev); + ++ return i915_drm_thaw_early(dev); ++} ++ ++int i915_resume(struct drm_device *dev) ++{ ++ struct drm_i915_private *dev_priv = dev->dev_private; ++ int ret; ++ + /* + * Platforms with opregion should have sane BIOS, older ones (gen3 and + * earlier) need to restore the GTT mappings since the BIOS might clear +@@ -726,6 +743,14 @@ int i915_resume(struct drm_device *dev) + return 0; + } + ++static int i915_resume_legacy(struct drm_device *dev) ++{ ++ i915_resume_early(dev); ++ i915_resume(dev); ++ ++ return 0; ++} ++ + /** + * i915_reset - reset chip after a hang + * @dev: drm device to reset +@@ -846,7 +871,6 @@ static int i915_pm_suspend(struct device + { + struct pci_dev *pdev = to_pci_dev(dev); + struct drm_device *drm_dev = pci_get_drvdata(pdev); +- int error; + + if (!drm_dev || !drm_dev->dev_private) { + dev_err(dev, "DRM not initialized, aborting suspend.\n"); +@@ -856,9 +880,25 @@ static int i915_pm_suspend(struct device + if (drm_dev->switch_power_state == DRM_SWITCH_POWER_OFF) + return 0; + +- error = i915_drm_freeze(drm_dev); +- if (error) +- return error; ++ return i915_drm_freeze(drm_dev); ++} ++ ++static int i915_pm_suspend_late(struct device *dev) ++{ ++ struct pci_dev *pdev = to_pci_dev(dev); ++ struct drm_device *drm_dev = pci_get_drvdata(pdev); ++ ++ /* ++ * We have a suspedn ordering issue with the snd-hda driver also ++ * requiring our device to be power up. Due to the lack of a ++ * parent/child relationship we currently solve this with an late ++ * suspend hook. ++ * ++ * FIXME: This should be solved with a special hdmi sink device or ++ * similar so that power domains can be employed. ++ */ ++ if (drm_dev->switch_power_state == DRM_SWITCH_POWER_OFF) ++ return 0; + + pci_disable_device(pdev); + pci_set_power_state(pdev, PCI_D3hot); +@@ -866,6 +906,14 @@ static int i915_pm_suspend(struct device + return 0; + } + ++static int i915_pm_resume_early(struct device *dev) ++{ ++ struct pci_dev *pdev = to_pci_dev(dev); ++ struct drm_device *drm_dev = pci_get_drvdata(pdev); ++ ++ return i915_resume_early(drm_dev); ++} ++ + static int i915_pm_resume(struct device *dev) + { + struct pci_dev *pdev = to_pci_dev(dev); +@@ -887,6 +935,14 @@ static int i915_pm_freeze(struct device + return i915_drm_freeze(drm_dev); + } + ++static int i915_pm_thaw_early(struct device *dev) ++{ ++ struct pci_dev *pdev = to_pci_dev(dev); ++ struct drm_device *drm_dev = pci_get_drvdata(pdev); ++ ++ return i915_drm_thaw_early(drm_dev); ++} ++ + static int i915_pm_thaw(struct device *dev) + { + struct pci_dev *pdev = to_pci_dev(dev); +@@ -948,10 +1004,14 @@ static int i915_runtime_resume(struct de + + static const struct dev_pm_ops i915_pm_ops = { + .suspend = i915_pm_suspend, ++ .suspend_late = i915_pm_suspend_late, ++ .resume_early = i915_pm_resume_early, + .resume = i915_pm_resume, + .freeze = i915_pm_freeze, ++ .thaw_early = i915_pm_thaw_early, + .thaw = i915_pm_thaw, + .poweroff = i915_pm_poweroff, ++ .restore_early = i915_pm_resume_early, + .restore = i915_pm_resume, + .runtime_suspend = i915_runtime_suspend, + .runtime_resume = i915_runtime_resume, +@@ -994,7 +1054,7 @@ static struct drm_driver driver = { + + /* Used in place of i915_pm_ops for non-DRIVER_MODESET */ + .suspend = i915_suspend, +- .resume = i915_resume, ++ .resume = i915_resume_legacy, + + .device_is_agp = i915_driver_device_is_agp, + .master_create = i915_master_create, diff --git a/queue-3.14/drm-i915-quirk-invert-brightness-for-acer-aspire-5336.patch b/queue-3.14/drm-i915-quirk-invert-brightness-for-acer-aspire-5336.patch new file mode 100644 index 00000000000..de199d06382 --- /dev/null +++ b/queue-3.14/drm-i915-quirk-invert-brightness-for-acer-aspire-5336.patch @@ -0,0 +1,58 @@ +From daniel.vetter@ffwll.ch Tue Jun 3 23:14:20 2014 +From: Daniel Vetter +Date: Wed, 21 May 2014 11:07:25 +0200 +Subject: drm/i915: quirk invert brightness for Acer Aspire 5336 +To: stable@vger.kernel.org +Cc: Intel Graphics Development , Jani Nikula , Daniel Vetter +Message-ID: <1400663245-15601-5-git-send-email-daniel.vetter@ffwll.ch> + + +From: Jani Nikula + +This is commit 0f540c3a7cfb91c9d7a19eb0c95c24 upstream. + +Since +commit ee1452d7458451a7508e0663553ce88d63958157 +Author: Jani Nikula +Date: Fri Sep 20 15:05:30 2013 +0300 + + drm/i915: assume all GM45 Acer laptops use inverted backlight PWM + +failed and was later reverted in +commit be505f643925e257087247b996cd8ece787c12af +Author: Alexander van Heukelum +Date: Sat Dec 28 21:00:39 2013 +0100 + + Revert "drm/i915: assume all GM45 Acer laptops use inverted backlight PWM" + +fix the individual broken machine instead. + +Note to backporters: + +http://patchwork.freedesktop.org/patch/17837/ + +is the patch you want for 3.13 and older. + +Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=54171 +Reference: http://mid.gmane.org/DUB115-W7628C7C710EA51AA110CD4A5000@phx.gbl +Signed-off-by: Jani Nikula +Reviewed-by: Ville Syrjälä +[danvet: Patch mangling for 3.14 plus adding the link to the original +for 3.13.] +Signed-off-by: Daniel Vetter +--- + drivers/gpu/drm/i915/intel_display.c | 3 +++ + 1 file changed, 3 insertions(+) + +--- a/drivers/gpu/drm/i915/intel_display.c ++++ b/drivers/gpu/drm/i915/intel_display.c +@@ -10862,6 +10862,9 @@ static struct intel_quirk intel_quirks[] + /* Acer Aspire 4736Z */ + { 0x2a42, 0x1025, 0x0260, quirk_invert_brightness }, + ++ /* Acer Aspire 5336 */ ++ { 0x2a42, 0x1025, 0x048a, quirk_invert_brightness }, ++ + /* Dell XPS13 HD Sandy Bridge */ + { 0x0116, 0x1028, 0x052e, quirk_no_pcm_pwm_enable }, + /* Dell XPS13 HD and XPS13 FHD Ivy Bridge */ diff --git a/queue-3.14/iscsi-target-change-bug_on-to-reject-in-iscsit_process_nop_out.patch b/queue-3.14/iscsi-target-change-bug_on-to-reject-in-iscsit_process_nop_out.patch new file mode 100644 index 00000000000..3fac7999eab --- /dev/null +++ b/queue-3.14/iscsi-target-change-bug_on-to-reject-in-iscsit_process_nop_out.patch @@ -0,0 +1,45 @@ +From 7cbfcc953789ff864c2bf8365a82a3fba4869649 Mon Sep 17 00:00:00 2001 +From: Nicholas Bellinger +Date: Thu, 1 May 2014 13:44:56 -0700 +Subject: iscsi-target: Change BUG_ON to REJECT in iscsit_process_nop_out + +From: Nicholas Bellinger + +commit 7cbfcc953789ff864c2bf8365a82a3fba4869649 upstream. + +This patch changes an incorrect use of BUG_ON to instead generate a +REJECT + PROTOCOL_ERROR in iscsit_process_nop_out() code. This case +can occur with traditional TCP where a flood of zeros in the data +stream can reach this block for what is presumed to be a NOP-OUT with +a solicited reply, but without a valid iscsi_cmd pointer. + +This incorrect BUG_ON was introduced during the v3.11-rc timeframe +with the following commit: + +commit 778de368964c5b7e8100cde9f549992d521e9c89 +Author: Nicholas Bellinger +Date: Fri Jun 14 16:07:47 2013 -0700 + + iscsi/isert-target: Refactor ISCSI_OP_NOOP RX handling + +Reported-by: Arshad Hussain +Signed-off-by: Nicholas Bellinger +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/target/iscsi/iscsi_target.c | 4 +++- + 1 file changed, 3 insertions(+), 1 deletion(-) + +--- a/drivers/target/iscsi/iscsi_target.c ++++ b/drivers/target/iscsi/iscsi_target.c +@@ -1564,7 +1564,9 @@ int iscsit_process_nop_out(struct iscsi_ + * Initiator is expecting a NopIN ping reply.. + */ + if (hdr->itt != RESERVED_ITT) { +- BUG_ON(!cmd); ++ if (!cmd) ++ return iscsit_add_reject(conn, ISCSI_REASON_PROTOCOL_ERROR, ++ (unsigned char *)hdr); + + spin_lock_bh(&conn->cmd_lock); + list_add_tail(&cmd->i_conn_node, &conn->conn_cmd_list); diff --git a/queue-3.14/series b/queue-3.14/series index 65747e9a673..34a1121c034 100644 --- a/queue-3.14/series +++ b/queue-3.14/series @@ -172,3 +172,13 @@ x86-64-modify_ldt-make-support-for-16-bit-segments-a-runtime-option.patch genirq-provide-irq_force_affinity-fallback-for-non-smp.patch sysfs-make-sure-read-buffer-is-zeroed.patch pci-shpchp-check-bridge-s-secondary-not-primary-bus-speed.patch +target-allow-non-supporting-backends-to-set-pi_prot_type-to-0.patch +target-iser-fix-wrong-connection-requests-list-addition.patch +target-iser-fix-iscsit_accept_np-and-rdma_cm-racy-flow.patch +iscsi-target-change-bug_on-to-reject-in-iscsit_process_nop_out.patch +target-don-t-allow-setting-wc-emulation-if-device-doesn-t-support.patch +target-fix-memory-leak-on-xcopy.patch +drm-i915-disable-self-refresh-for-untiled-fbs-on-i915gm.patch +drm-i915-move-power-domain-init-earlier-during-system-resume.patch +drm-i915-fix-unsafe-loop-iteration-over-vma-whilst-unbinding-them.patch +drm-i915-quirk-invert-brightness-for-acer-aspire-5336.patch diff --git a/queue-3.14/target-allow-non-supporting-backends-to-set-pi_prot_type-to-0.patch b/queue-3.14/target-allow-non-supporting-backends-to-set-pi_prot_type-to-0.patch new file mode 100644 index 00000000000..2c92101d086 --- /dev/null +++ b/queue-3.14/target-allow-non-supporting-backends-to-set-pi_prot_type-to-0.patch @@ -0,0 +1,37 @@ +From 448ba904160f9d8f69217c28a1692cee5afbff88 Mon Sep 17 00:00:00 2001 +From: Andy Grover +Date: Tue, 15 Apr 2014 14:13:12 -0700 +Subject: target: Allow non-supporting backends to set pi_prot_type to 0 + +From: Andy Grover + +commit 448ba904160f9d8f69217c28a1692cee5afbff88 upstream. + +Userspace tools assume if a value is read from configfs, it is valid +and will not cause an error if the same value is written back. The only +valid value for pi_prot_type for backends not supporting DIF is 0, so allow +this particular value to be set without returning an error. + +Reported-by: Krzysztof Chojnowski +Signed-off-by: Andy Grover +Reviewed-by: Sagi Grimberg +Signed-off-by: Nicholas Bellinger +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/target/target_core_device.c | 4 ++++ + 1 file changed, 4 insertions(+) + +--- a/drivers/target/target_core_device.c ++++ b/drivers/target/target_core_device.c +@@ -936,6 +936,10 @@ int se_dev_set_pi_prot_type(struct se_de + return 0; + } + if (!dev->transport->init_prot || !dev->transport->free_prot) { ++ /* 0 is only allowed value for non-supporting backends */ ++ if (flag == 0) ++ return 0; ++ + pr_err("DIF protection not supported by backend: %s\n", + dev->transport->name); + return -ENOSYS; diff --git a/queue-3.14/target-don-t-allow-setting-wc-emulation-if-device-doesn-t-support.patch b/queue-3.14/target-don-t-allow-setting-wc-emulation-if-device-doesn-t-support.patch new file mode 100644 index 00000000000..700811801bb --- /dev/null +++ b/queue-3.14/target-don-t-allow-setting-wc-emulation-if-device-doesn-t-support.patch @@ -0,0 +1,40 @@ +From 07b8dae38b09bcfede7e726f172e39b5ce8390d9 Mon Sep 17 00:00:00 2001 +From: Andy Grover +Date: Wed, 14 May 2014 15:48:06 -0700 +Subject: target: Don't allow setting WC emulation if device doesn't support + +From: Andy Grover + +commit 07b8dae38b09bcfede7e726f172e39b5ce8390d9 upstream. + +Just like for pSCSI, if the transport sets get_write_cache, then it is +not valid to enable write cache emulation for it. Return an error. + +see https://bugzilla.redhat.com/show_bug.cgi?id=1082675 + +Reviewed-by: Chris Leech +Signed-off-by: Andy Grover +Signed-off-by: Nicholas Bellinger +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/target/target_core_device.c | 8 ++++---- + 1 file changed, 4 insertions(+), 4 deletions(-) + +--- a/drivers/target/target_core_device.c ++++ b/drivers/target/target_core_device.c +@@ -798,10 +798,10 @@ int se_dev_set_emulate_write_cache(struc + pr_err("emulate_write_cache not supported for pSCSI\n"); + return -EINVAL; + } +- if (dev->transport->get_write_cache) { +- pr_warn("emulate_write_cache cannot be changed when underlying" +- " HW reports WriteCacheEnabled, ignoring request\n"); +- return 0; ++ if (flag && ++ dev->transport->get_write_cache) { ++ pr_err("emulate_write_cache not supported for this device\n"); ++ return -EINVAL; + } + + dev->dev_attrib.emulate_write_cache = flag; diff --git a/queue-3.14/target-fix-memory-leak-on-xcopy.patch b/queue-3.14/target-fix-memory-leak-on-xcopy.patch new file mode 100644 index 00000000000..0c4348605c4 --- /dev/null +++ b/queue-3.14/target-fix-memory-leak-on-xcopy.patch @@ -0,0 +1,51 @@ +From 1e1110c43b1cda9fe77fc4a04835e460550e6b3c Mon Sep 17 00:00:00 2001 +From: Mikulas Patocka +Date: Sat, 17 May 2014 06:49:22 -0400 +Subject: target: fix memory leak on XCOPY + +From: Mikulas Patocka + +commit 1e1110c43b1cda9fe77fc4a04835e460550e6b3c upstream. + +On each processed XCOPY command, two "kmalloc-512" memory objects are +leaked. These represent two allocations of struct xcopy_pt_cmd in +target_core_xcopy.c. + +The reason for the memory leak is that the cmd_kref field is not +initialized (thus, it is zero because the allocations were done with +kzalloc). When we decrement zero kref in target_put_sess_cmd, the result +is not zero, thus target_release_cmd_kref is not called. + +This patch fixes the bug by moving kref initialization from +target_get_sess_cmd to transport_init_se_cmd (this function is called from +target_core_xcopy.c, so it will correctly initialize cmd_kref). It can be +easily verified that all code that calls target_get_sess_cmd also calls +transport_init_se_cmd earlier, thus moving kref_init shouldn't introduce +any new problems. + +Signed-off-by: Mikulas Patocka +Signed-off-by: Nicholas Bellinger +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/target/target_core_transport.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/target/target_core_transport.c ++++ b/drivers/target/target_core_transport.c +@@ -1102,6 +1102,7 @@ void transport_init_se_cmd( + init_completion(&cmd->cmd_wait_comp); + init_completion(&cmd->task_stop_comp); + spin_lock_init(&cmd->t_state_lock); ++ kref_init(&cmd->cmd_kref); + cmd->transport_state = CMD_T_DEV_ACTIVE; + + cmd->se_tfo = tfo; +@@ -2292,7 +2293,6 @@ int target_get_sess_cmd(struct se_sessio + unsigned long flags; + int ret = 0; + +- kref_init(&se_cmd->cmd_kref); + /* + * Add a second kref if the fabric caller is expecting to handle + * fabric acknowledgement that requires two target_put_sess_cmd() diff --git a/queue-3.14/target-iser-fix-iscsit_accept_np-and-rdma_cm-racy-flow.patch b/queue-3.14/target-iser-fix-iscsit_accept_np-and-rdma_cm-racy-flow.patch new file mode 100644 index 00000000000..db1beffe6e4 --- /dev/null +++ b/queue-3.14/target-iser-fix-iscsit_accept_np-and-rdma_cm-racy-flow.patch @@ -0,0 +1,112 @@ +From 531b7bf4bd795d9a09eac92504322a472c010bc8 Mon Sep 17 00:00:00 2001 +From: Sagi Grimberg +Date: Tue, 29 Apr 2014 13:13:45 +0300 +Subject: Target/iser: Fix iscsit_accept_np and rdma_cm racy flow + +From: Sagi Grimberg + +commit 531b7bf4bd795d9a09eac92504322a472c010bc8 upstream. + +RDMA CM and iSCSI target flows are asynchronous and completely +uncorrelated. Relying on the fact that iscsi_accept_np will be called +after CM connection request event and will wait for it is a mistake. + +When attempting to login to a few targets this flow is racy and +unpredictable, but for parallel login to dozens of targets will +race and hang every time. + +The correct synchronizing mechanism in this case is pending on +a semaphore rather than a wait_for_event. We keep the pending +interruptible for iscsi_np cleanup stage. + +(Squash patch to remove dead code into parent - nab) + +Reported-by: Slava Shwartsman +Signed-off-by: Sagi Grimberg +Signed-off-by: Nicholas Bellinger +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/infiniband/ulp/isert/ib_isert.c | 25 ++++++------------------- + drivers/infiniband/ulp/isert/ib_isert.h | 2 +- + 2 files changed, 7 insertions(+), 20 deletions(-) + +--- a/drivers/infiniband/ulp/isert/ib_isert.c ++++ b/drivers/infiniband/ulp/isert/ib_isert.c +@@ -28,6 +28,7 @@ + #include + #include + #include ++#include + + #include "isert_proto.h" + #include "ib_isert.h" +@@ -585,8 +586,8 @@ isert_connect_request(struct rdma_cm_id + list_add_tail(&isert_conn->conn_accept_node, &isert_np->np_accept_list); + mutex_unlock(&isert_np->np_accept_mutex); + +- pr_debug("isert_connect_request() waking up np_accept_wq: %p\n", np); +- wake_up(&isert_np->np_accept_wq); ++ pr_debug("isert_connect_request() up np_sem np: %p\n", np); ++ up(&isert_np->np_sem); + return 0; + + out_conn_dev: +@@ -2569,7 +2570,7 @@ isert_setup_np(struct iscsi_np *np, + pr_err("Unable to allocate struct isert_np\n"); + return -ENOMEM; + } +- init_waitqueue_head(&isert_np->np_accept_wq); ++ sema_init(&isert_np->np_sem, 0); + mutex_init(&isert_np->np_accept_mutex); + INIT_LIST_HEAD(&isert_np->np_accept_list); + init_completion(&isert_np->np_login_comp); +@@ -2618,18 +2619,6 @@ out: + } + + static int +-isert_check_accept_queue(struct isert_np *isert_np) +-{ +- int empty; +- +- mutex_lock(&isert_np->np_accept_mutex); +- empty = list_empty(&isert_np->np_accept_list); +- mutex_unlock(&isert_np->np_accept_mutex); +- +- return empty; +-} +- +-static int + isert_rdma_accept(struct isert_conn *isert_conn) + { + struct rdma_cm_id *cm_id = isert_conn->conn_cm_id; +@@ -2721,16 +2710,14 @@ isert_accept_np(struct iscsi_np *np, str + int max_accept = 0, ret; + + accept_wait: +- ret = wait_event_interruptible(isert_np->np_accept_wq, +- !isert_check_accept_queue(isert_np) || +- np->np_thread_state == ISCSI_NP_THREAD_RESET); ++ ret = down_interruptible(&isert_np->np_sem); + if (max_accept > 5) + return -ENODEV; + + spin_lock_bh(&np->np_thread_lock); + if (np->np_thread_state == ISCSI_NP_THREAD_RESET) { + spin_unlock_bh(&np->np_thread_lock); +- pr_err("ISCSI_NP_THREAD_RESET for isert_accept_np\n"); ++ pr_debug("ISCSI_NP_THREAD_RESET for isert_accept_np\n"); + return -ENODEV; + } + spin_unlock_bh(&np->np_thread_lock); +--- a/drivers/infiniband/ulp/isert/ib_isert.h ++++ b/drivers/infiniband/ulp/isert/ib_isert.h +@@ -158,7 +158,7 @@ struct isert_device { + }; + + struct isert_np { +- wait_queue_head_t np_accept_wq; ++ struct semaphore np_sem; + struct rdma_cm_id *np_cm_id; + struct mutex np_accept_mutex; + struct list_head np_accept_list; diff --git a/queue-3.14/target-iser-fix-wrong-connection-requests-list-addition.patch b/queue-3.14/target-iser-fix-wrong-connection-requests-list-addition.patch new file mode 100644 index 00000000000..65dedd35fdf --- /dev/null +++ b/queue-3.14/target-iser-fix-wrong-connection-requests-list-addition.patch @@ -0,0 +1,31 @@ +From 9fe63c88b1d59f1ce054d6948ccd3096496ecedb Mon Sep 17 00:00:00 2001 +From: Sagi Grimberg +Date: Tue, 29 Apr 2014 13:13:44 +0300 +Subject: Target/iser: Fix wrong connection requests list addition + +From: Sagi Grimberg + +commit 9fe63c88b1d59f1ce054d6948ccd3096496ecedb upstream. + +Should be adding list_add_tail($new, $head) and not +the other way around. + +Signed-off-by: Sagi Grimberg +Signed-off-by: Nicholas Bellinger +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/infiniband/ulp/isert/ib_isert.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/infiniband/ulp/isert/ib_isert.c ++++ b/drivers/infiniband/ulp/isert/ib_isert.c +@@ -582,7 +582,7 @@ isert_connect_request(struct rdma_cm_id + goto out_conn_dev; + + mutex_lock(&isert_np->np_accept_mutex); +- list_add_tail(&isert_np->np_accept_list, &isert_conn->conn_accept_node); ++ list_add_tail(&isert_conn->conn_accept_node, &isert_np->np_accept_list); + mutex_unlock(&isert_np->np_accept_mutex); + + pr_debug("isert_connect_request() waking up np_accept_wq: %p\n", np); -- 2.47.3