This is the start of the stable review cycle for the 3.11.1 release.
There are 16 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 Sat Sep 14 18:10:15 UTC 2013.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.11.1-rc1.gz
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
-------------
Diffstat:
3.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sangjung Woo <[email protected]>
commit 1748cbf7f7c464593232cde914f5a103181a83b5 upstream.
Fix a read of the wrong register when checking whether the RTC timer has
reached the alarm time.
Signed-off-by: Sangjung Woo <[email protected]>
Signed-off-by: Myugnjoo Ham <[email protected]>
Reviewed-by: Jonghwa Lee <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Jonghwan Choi <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/rtc/rtc-max77686.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/rtc/rtc-max77686.c
+++ b/drivers/rtc/rtc-max77686.c
@@ -240,9 +240,9 @@ static int max77686_rtc_read_alarm(struc
}
alrm->pending = 0;
- ret = regmap_read(info->max77686->regmap, MAX77686_REG_STATUS1, &val);
+ ret = regmap_read(info->max77686->regmap, MAX77686_REG_STATUS2, &val);
if (ret < 0) {
- dev_err(info->dev, "%s:%d fail to read status1 reg(%d)\n",
+ dev_err(info->dev, "%s:%d fail to read status2 reg(%d)\n",
__func__, __LINE__, ret);
goto out;
}
3.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Lan Tianyu <[email protected]>
commit 524f42fab787a9510be826ce3d736b56d454ac6d upstream.
The ECDT of ASUSTEK L4R doesn't provide correct command and data
I/O ports. The DSDT provides the correct information instead.
For this reason, add this machine to quirk list for ECDT validation
and use the EC information from the DSDT.
[rjw: Changelog]
References: https://bugzilla.kernel.org/show_bug.cgi?id=60765
Reported-and-tested-by: Daniele Esposti <[email protected]>
Signed-off-by: Lan Tianyu <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/acpi/ec.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/drivers/acpi/ec.c
+++ b/drivers/acpi/ec.c
@@ -987,6 +987,10 @@ static struct dmi_system_id __initdata e
ec_skip_dsdt_scan, "HP Folio 13", {
DMI_MATCH(DMI_SYS_VENDOR, "Hewlett-Packard"),
DMI_MATCH(DMI_PRODUCT_NAME, "HP Folio 13"),}, NULL},
+ {
+ ec_validate_ecdt, "ASUS hardware", {
+ DMI_MATCH(DMI_SYS_VENDOR, "ASUSTek Computer Inc."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "L4R"),}, NULL},
{},
};
3.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Wei Hu <[email protected]>
commit 30b146d1cb5e7560192057098eb705118bd5511f upstream.
The temperature reporting interface stays the same, so we just
add the PCI-ID to the list.
Verified on AMD Olive Hill.
Signed-off-by: Wei Hu <[email protected]>
Acked-by: Clemens Ladisch <[email protected]>
Signed-off-by: Guenter Roeck <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
Documentation/hwmon/k10temp | 1 +
drivers/hwmon/Kconfig | 4 ++--
drivers/hwmon/k10temp.c | 3 ++-
3 files changed, 5 insertions(+), 3 deletions(-)
--- a/Documentation/hwmon/k10temp
+++ b/Documentation/hwmon/k10temp
@@ -12,6 +12,7 @@ Supported chips:
* AMD Family 12h processors: "Llano" (E2/A4/A6/A8-Series)
* AMD Family 14h processors: "Brazos" (C/E/G/Z-Series)
* AMD Family 15h processors: "Bulldozer" (FX-Series), "Trinity"
+* AMD Family 16h processors: "Kabini"
Prefix: 'k10temp'
Addresses scanned: PCI space
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -296,8 +296,8 @@ config SENSORS_K10TEMP
If you say yes here you get support for the temperature
sensor(s) inside your CPU. Supported are later revisions of
the AMD Family 10h and all revisions of the AMD Family 11h,
- 12h (Llano), 14h (Brazos) and 15h (Bulldozer/Trinity)
- microarchitectures.
+ 12h (Llano), 14h (Brazos), 15h (Bulldozer/Trinity) and
+ 16h (Kabini) microarchitectures.
This driver can also be built as a module. If so, the module
will be called k10temp.
--- a/drivers/hwmon/k10temp.c
+++ b/drivers/hwmon/k10temp.c
@@ -1,5 +1,5 @@
/*
- * k10temp.c - AMD Family 10h/11h/12h/14h/15h processor hardware monitoring
+ * k10temp.c - AMD Family 10h/11h/12h/14h/15h/16h processor hardware monitoring
*
* Copyright (c) 2009 Clemens Ladisch <[email protected]>
*
@@ -211,6 +211,7 @@ static DEFINE_PCI_DEVICE_TABLE(k10temp_i
{ PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_CNB17H_F3) },
{ PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_15H_NB_F3) },
{ PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_15H_M10H_F3) },
+ { PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_16H_NB_F3) },
{}
};
MODULE_DEVICE_TABLE(pci, k10temp_id_table);
3.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: "K. Y. Srinivasan" <[email protected]>
commit 42dceebe34600b2d02a38baa3e869009ba3d14c7 upstream.
The channel state should be correctly set before registering the device. In the current
code the driver probe would fail for channels that have been rescinded and subsequently
re-offered. Fix the bug.
Signed-off-by: K. Y. Srinivasan <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/hv/channel_mgmt.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
--- a/drivers/hv/channel_mgmt.c
+++ b/drivers/hv/channel_mgmt.c
@@ -262,6 +262,13 @@ static void vmbus_process_offer(struct w
}
/*
+ * This state is used to indicate a successful open
+ * so that when we do close the channel normally, we
+ * can cleanup properly
+ */
+ newchannel->state = CHANNEL_OPEN_STATE;
+
+ /*
* Start the process of binding this offer to the driver
* We need to set the DeviceObject field before calling
* vmbus_child_dev_add()
@@ -287,13 +294,6 @@ static void vmbus_process_offer(struct w
kfree(newchannel->device_obj);
free_channel(newchannel);
- } else {
- /*
- * This state is used to indicate a successful open
- * so that when we do close the channel normally, we
- * can cleanup properly
- */
- newchannel->state = CHANNEL_OPEN_STATE;
}
}
3.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Bing Zhao <[email protected]>
commit 1211c961170cedb21c30d5bb7e2033c8720b38db upstream.
Bug 60747 - 1286:2044 [Microsoft Surface Pro]
Marvell 88W8797 wifi show 3 interface under network
https://bugzilla.kernel.org/show_bug.cgi?id=60747
This issue was also reported previously by OLPC and some folks from
the community.
There are 3 network interfaces with different types being created
when mwifiex driver is loaded:
1. mlan0 (infra. STA)
2. uap0 (AP)
3. p2p0 (P2P_CLIENT)
The Network Manager attempts to use all 3 interfaces above without
filtering the managed interface type. As the result, 3 identical
interfaces are displayed under network manager. If user happens to
click on an entry under which its interface is uap0 or p2p0, the
association will fail.
Work around it by removing the creation of AP and P2P interfaces
at driver loading time. These interfaces can be added with 'iw' or
other applications manually when they are needed.
Signed-off-by: Bing Zhao <[email protected]>
Signed-off-by: Avinash Patil <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/wireless/mwifiex/main.c | 14 --------------
1 file changed, 14 deletions(-)
--- a/drivers/net/wireless/mwifiex/main.c
+++ b/drivers/net/wireless/mwifiex/main.c
@@ -458,20 +458,6 @@ static void mwifiex_fw_dpc(const struct
dev_err(adapter->dev, "cannot create default STA interface\n");
goto err_add_intf;
}
-
- /* Create AP interface by default */
- if (!mwifiex_add_virtual_intf(adapter->wiphy, "uap%d",
- NL80211_IFTYPE_AP, NULL, NULL)) {
- dev_err(adapter->dev, "cannot create default AP interface\n");
- goto err_add_intf;
- }
-
- /* Create P2P interface by default */
- if (!mwifiex_add_virtual_intf(adapter->wiphy, "p2p%d",
- NL80211_IFTYPE_P2P_CLIENT, NULL, NULL)) {
- dev_err(adapter->dev, "cannot create default P2P interface\n");
- goto err_add_intf;
- }
rtnl_unlock();
mwifiex_drv_get_driver_version(adapter, fmt, sizeof(fmt) - 1);
3.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: John Haxby <[email protected]>
commit edb6f29464afc65fc73767540b854abf63ae7144 upstream.
This affects xen pv guests with sufficiently old versions of xen and
sufficiently new hardware. On such a system, a guest with a btrfs
root won't even boot.
Signed-off-by: John Haxby <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
Reported-by: Michael Marineau <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/x86/include/asm/xor_avx.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/arch/x86/include/asm/xor_avx.h
+++ b/arch/x86/include/asm/xor_avx.h
@@ -167,12 +167,12 @@ static struct xor_block_template xor_blo
#define AVX_XOR_SPEED \
do { \
- if (cpu_has_avx) \
+ if (cpu_has_avx && cpu_has_osxsave) \
xor_speed(&xor_block_avx); \
} while (0)
#define AVX_SELECT(FASTEST) \
- (cpu_has_avx ? &xor_block_avx : FASTEST)
+ (cpu_has_avx && cpu_has_osxsave ? &xor_block_avx : FASTEST)
#else
3.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Fabio Estevam <[email protected]>
commit 3f1a91aa25579ba5e7268a47a73d2a83e4802c62 upstream.
Building imx_v6_v7_defconfig with all audio drivers as modules results in
the folowing build error:
ERROR: "imx_pcm_fiq_init" [sound/soc/fsl/snd-soc-imx-ssi.ko] undefined!
ERROR: "imx_pcm_dma_init" [sound/soc/fsl/snd-soc-imx-ssi.ko] undefined!
ERROR: "imx_pcm_fiq_exit" [sound/soc/fsl/snd-soc-imx-ssi.ko] undefined!
ERROR: "imx_pcm_dma_exit" [sound/soc/fsl/snd-soc-imx-ssi.ko] undefined!
ERROR: "imx_pcm_dma_init" [sound/soc/fsl/snd-soc-fsl-ssi.ko] undefined!
ERROR: "imx_pcm_dma_exit" [sound/soc/fsl/snd-soc-fsl-ssi.ko] undefined!
Fix this by allowing SND_SOC_IMX_PCM_FIQ and SND_SOC_IMX_PCM_DMA to be also
built as modules and by using 'IS_ENABLED' to cover the module case.
Reported-by: Guennadi Liakhovetski <[email protected]>
Signed-off-by: Fabio Estevam <[email protected]>
Acked-by: Shawn Guo <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
[Guenter Roeck: back-ported to 3.11]
Signed-off-by: Guenter Roeck <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
sound/soc/fsl/Kconfig | 4 ++--
sound/soc/fsl/imx-pcm.h | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
--- a/sound/soc/fsl/Kconfig
+++ b/sound/soc/fsl/Kconfig
@@ -109,11 +109,11 @@ config SND_SOC_IMX_SSI
tristate
config SND_SOC_IMX_PCM_FIQ
- bool
+ tristate
select FIQ
config SND_SOC_IMX_PCM_DMA
- bool
+ tristate
select SND_SOC_GENERIC_DMAENGINE_PCM
config SND_SOC_IMX_AUDMUX
--- a/sound/soc/fsl/imx-pcm.h
+++ b/sound/soc/fsl/imx-pcm.h
@@ -32,7 +32,7 @@ imx_pcm_dma_params_init_data(struct imx_
dma_data->peripheral_type = IMX_DMATYPE_SSI;
}
-#ifdef CONFIG_SND_SOC_IMX_PCM_DMA
+#if IS_ENABLED(CONFIG_SND_SOC_IMX_PCM_DMA)
int imx_pcm_dma_init(struct platform_device *pdev);
void imx_pcm_dma_exit(struct platform_device *pdev);
#else
@@ -46,7 +46,7 @@ static inline void imx_pcm_dma_exit(stru
}
#endif
-#ifdef CONFIG_SND_SOC_IMX_PCM_FIQ
+#if IS_ENABLED(CONFIG_SND_SOC_IMX_PCM_FIQ)
int imx_pcm_fiq_init(struct platform_device *pdev);
void imx_pcm_fiq_exit(struct platform_device *pdev);
#else
3.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Fabio Estevam <[email protected]>
commit ea8d15832016b0d07a8121159904e6b1d21b5b8b upstream.
When building imx_v6_v7_defconfig with imx-drm drivers selected as modules, we
get the following build error:
ERROR: "imx_drm_encoder_get_mux_id" [drivers/staging/imx-drm/imx-ldb.ko] undefined!
Export the required function to avoid this problem.
Signed-off-by: Fabio Estevam <[email protected]>
Acked-by: Sascha Hauer <[email protected]>
Acked-by: Philipp Zabel <[email protected]>
Cc: Guenter Roeck <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/staging/imx-drm/imx-drm-core.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/staging/imx-drm/imx-drm-core.c
+++ b/drivers/staging/imx-drm/imx-drm-core.c
@@ -678,6 +678,7 @@ found:
return i;
}
+EXPORT_SYMBOL_GPL(imx_drm_encoder_get_mux_id);
/*
* imx_drm_remove_encoder - remove an encoder
3.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mark Rusk <[email protected]>
commit eefbc594abbb1b7e6e7eeadb65ae7c7538474210 upstream.
Using an uninitialized variable 'devnum' after 'goto out;' was causing
panic. Just go ahead and return, we need to ignore AUX iLO devs.
Oops: 0002 [#1] SMP
.
.
.
RIP [<ffffffffa033e270>] ilo_probe+0xec/0xe7c [hpilo]
Signed-off-by: Mark Rusk <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/misc/hpilo.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/misc/hpilo.c
+++ b/drivers/misc/hpilo.c
@@ -759,7 +759,7 @@ static int ilo_probe(struct pci_dev *pde
/* Ignore subsystem_device = 0x1979 (set by BIOS) */
if (pdev->subsystem_device == 0x1979)
- goto out;
+ return 0;
if (max_ccb > MAX_CCB)
max_ccb = MAX_CCB;
@@ -899,7 +899,7 @@ static void __exit ilo_exit(void)
class_destroy(ilo_class);
}
-MODULE_VERSION("1.4");
+MODULE_VERSION("1.4.1");
MODULE_ALIAS(ILO_NAME);
MODULE_DESCRIPTION(ILO_NAME);
MODULE_AUTHOR("David Altobelli <[email protected]>");
Your script may be a bit buggered...
Linus
On Thu, Sep 12, 2013 at 11:14 AM, Greg Kroah-Hartman
<[email protected]> wrote:
>
> -------------
> Pseudo-Shortlog of commits:
>
>
> -------------
>
> Diffstat:
>
>
3.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Graham Williams <[email protected]>
commit d257221854f0b34cca3247e6c45344d0470f7398 upstream.
The gadget strings table should be null terminated.
usb_gadget_get_string() loops through the table
expecting a null at the end of the list.
Signed-off-by: Graham Williams <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/usb/gadget/f_acm.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/usb/gadget/f_acm.c
+++ b/drivers/usb/gadget/f_acm.c
@@ -285,6 +285,7 @@ static struct usb_string acm_string_defs
[ACM_CTRL_IDX].s = "CDC Abstract Control Model (ACM)",
[ACM_DATA_IDX].s = "CDC ACM Data",
[ACM_IAD_IDX ].s = "CDC Serial",
+ { } /* end of list */
};
static struct usb_gadget_strings acm_string_table = {
3.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tomas Winkler <[email protected]>
commit ff96066e3171acdea356b331163495957cb833d0 upstream.
Both H_IS and H_IE needs to be set to receive H_RDY
interrupt
1. Assert H_IS to clear the interrupts during hw reset
and use mei_me_reg_write instead of mei_hcsr_set as the later
strips down the H_IS
2. fix interrupt disablement embarrassing typo
hcsr |= ~H_IE -> hcsr &= ~H_IE;
this will remove the unwanted interrupt on power down
3. remove useless debug print outs
Signed-off-by: Tomas Winkler <[email protected]>
Cc: Shuah Khan <[email protected]>
Cc: Konstantin Khlebnikov <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/misc/mei/hw-me.c | 9 +++------
1 file changed, 3 insertions(+), 6 deletions(-)
--- a/drivers/misc/mei/hw-me.c
+++ b/drivers/misc/mei/hw-me.c
@@ -176,21 +176,18 @@ static int mei_me_hw_reset(struct mei_de
struct mei_me_hw *hw = to_me_hw(dev);
u32 hcsr = mei_hcsr_read(hw);
- dev_dbg(&dev->pdev->dev, "before reset HCSR = 0x%08x.\n", hcsr);
-
- hcsr |= (H_RST | H_IG);
+ hcsr |= H_RST | H_IG | H_IS;
if (intr_enable)
hcsr |= H_IE;
else
- hcsr |= ~H_IE;
+ hcsr &= ~H_IE;
- mei_hcsr_set(hw, hcsr);
+ mei_me_reg_write(hw, H_CSR, hcsr);
if (dev->dev_state == MEI_DEV_POWER_DOWN)
mei_me_hw_reset_release(dev);
- dev_dbg(&dev->pdev->dev, "current HCSR = 0x%08x.\n", mei_hcsr_read(hw));
return 0;
}
On Thu, Sep 12, 2013 at 11:17 AM, Linus Torvalds
<[email protected]> wrote:
> Your script may be a bit buggered...
Or maybe I should take that as a sign that 3.11 is doing really well?
I'll be optimistic.
Linus
3.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nicholas Bellinger <[email protected]>
commit c130480b129fbfd7932ad7af3f4ffcea630b027f upstream.
This patch addresses a v3.11 specific regression where se_cmd->state_list
was being leaked during a fabric WRITE failure, when the fabric releases
an associated se_cmd descriptor before I/O submission occurs, and normal
fast path callbacks have a chance to call target_remove_from_state_list().
It was manifesting with Poison overwritten messages with iscsi-target
once an ImmediateData payload CRC32C failure occured.
This bug was originally introduced during v3.11-rc1 with the following
commit:
commit 0b66818ac6de67a6125ae203272fb76e79b3a20f
Author: Nicholas Bellinger <[email protected]>
Date: Thu Jun 6 01:36:41 2013 -0700
target: Drop unnecessary CMD_T_DEV_ACTIVE check from transport_lun_remove_cmd
Signed-off-by: Nicholas Bellinger <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/target/target_core_transport.c | 11 +++++++++++
1 file changed, 11 insertions(+)
--- a/drivers/target/target_core_transport.c
+++ b/drivers/target/target_core_transport.c
@@ -2134,6 +2134,7 @@ static void transport_write_pending_qf(s
int transport_generic_free_cmd(struct se_cmd *cmd, int wait_for_tasks)
{
+ unsigned long flags;
int ret = 0;
if (!(cmd->se_cmd_flags & SCF_SE_LUN_CMD)) {
@@ -2144,6 +2145,16 @@ int transport_generic_free_cmd(struct se
} else {
if (wait_for_tasks)
transport_wait_for_tasks(cmd);
+ /*
+ * Handle WRITE failure case where transport_generic_new_cmd()
+ * has already added se_cmd to state_list, but fabric has
+ * failed command before I/O submission.
+ */
+ if (cmd->state_active) {
+ spin_lock_irqsave(&cmd->t_state_lock, flags);
+ target_remove_from_state_list(cmd);
+ spin_unlock_irqrestore(&cmd->t_state_lock, flags);
+ }
if (cmd->se_lun)
transport_lun_remove_cmd(cmd);
3.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nicholas Bellinger <[email protected]>
commit ee60bddba5a5f23e39598195d944aa0eb2d455e5 upstream.
This patch fixes spc_emulate_inquiry_std() to add trailing ASCII
spaces for INQUIRY vendor + model fields following SPC-4 text:
"ASCII data fields described as being left-aligned shall have any
unused bytes at the end of the field (i.e., highest offset) and
the unused bytes shall be filled with ASCII space characters (20h)."
This addresses a problem with Falconstor NSS multipathing.
Reported-by: Tomas Molota <[email protected]>
Signed-off-by: Nicholas Bellinger <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/target/target_core_spc.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
--- a/drivers/target/target_core_spc.c
+++ b/drivers/target/target_core_spc.c
@@ -97,9 +97,12 @@ spc_emulate_inquiry_std(struct se_cmd *c
buf[7] = 0x2; /* CmdQue=1 */
- snprintf(&buf[8], 8, "LIO-ORG");
- snprintf(&buf[16], 16, "%s", dev->t10_wwn.model);
- snprintf(&buf[32], 4, "%s", dev->t10_wwn.revision);
+ memcpy(&buf[8], "LIO-ORG ", 8);
+ memset(&buf[16], 0x20, 16);
+ memcpy(&buf[16], dev->t10_wwn.model,
+ min_t(size_t, strlen(dev->t10_wwn.model), 16));
+ memcpy(&buf[32], dev->t10_wwn.revision,
+ min_t(size_t, strlen(dev->t10_wwn.revision), 4));
buf[4] = 31; /* Set additional length to 31 */
return 0;
3.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nicholas Bellinger <[email protected]>
commit 28aaa950320fc7b8df3f6d2d34fa7833391a9b72 upstream.
This patch addresses a potential NULL pointer dereference regression in
iscsit_setup_nop_out() code, specifically for two cases when a solicited
NOPOUT triggers a ISCSI_REASON_PROTOCOL_ERROR reject to be generated.
This is because iscsi_cmd is expected to be NULL for solicited NOPOUT
case before iscsit_process_nop_out() locates the descriptor via TTT
using iscsit_find_cmd_from_ttt().
This regression was originally introduced in:
commit ba159914086f06532079fc15141f46ffe7e04a41
Author: Nicholas Bellinger <[email protected]>
Date: Wed Jul 3 03:48:24 2013 -0700
iscsi-target: Fix iscsit_add_reject* usage for iser
Signed-off-by: Nicholas Bellinger <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/target/iscsi/iscsi_target.c | 8 ++++++++
1 file changed, 8 insertions(+)
--- a/drivers/target/iscsi/iscsi_target.c
+++ b/drivers/target/iscsi/iscsi_target.c
@@ -1522,6 +1522,10 @@ int iscsit_setup_nop_out(struct iscsi_co
if (hdr->itt == RESERVED_ITT && !(hdr->opcode & ISCSI_OP_IMMEDIATE)) {
pr_err("NOPOUT ITT is reserved, but Immediate Bit is"
" not set, protocol error.\n");
+ if (!cmd)
+ return iscsit_add_reject(conn, ISCSI_REASON_PROTOCOL_ERROR,
+ (unsigned char *)hdr);
+
return iscsit_reject_cmd(cmd, ISCSI_REASON_PROTOCOL_ERROR,
(unsigned char *)hdr);
}
@@ -1531,6 +1535,10 @@ int iscsit_setup_nop_out(struct iscsi_co
" greater than MaxXmitDataSegmentLength: %u, protocol"
" error.\n", payload_length,
conn->conn_ops->MaxXmitDataSegmentLength);
+ if (!cmd)
+ return iscsit_add_reject(conn, ISCSI_REASON_PROTOCOL_ERROR,
+ (unsigned char *)hdr);
+
return iscsit_reject_cmd(cmd, ISCSI_REASON_PROTOCOL_ERROR,
(unsigned char *)hdr);
}
3.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nicholas Bellinger <[email protected]>
commit c9a03c12464c851e691e8d5b6c9deba779c512e0 upstream.
This patch fixes a bug in __iscsi_target_login_thread() where an explicit
network portal thread reset ends up leaking the iscsit_transport module
reference, along with the associated iscsi_conn allocation.
This manifests itself with iser-target where a NP reset causes the extra
iscsit_transport reference to be taken in iscsit_conn_set_transport()
during the reset, which prevents the ib_isert module from being unloaded
after the NP thread shutdown has finished.
Signed-off-by: Nicholas Bellinger <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/target/iscsi/iscsi_target_login.c | 9 ++++-----
1 file changed, 4 insertions(+), 5 deletions(-)
--- a/drivers/target/iscsi/iscsi_target_login.c
+++ b/drivers/target/iscsi/iscsi_target_login.c
@@ -1163,12 +1163,11 @@ static int __iscsi_target_login_thread(s
if (np->np_thread_state == ISCSI_NP_THREAD_RESET) {
spin_unlock_bh(&np->np_thread_lock);
complete(&np->np_restart_comp);
- if (ret == -ENODEV) {
- iscsit_put_transport(conn->conn_transport);
- kfree(conn);
- conn = NULL;
+ iscsit_put_transport(conn->conn_transport);
+ kfree(conn);
+ conn = NULL;
+ if (ret == -ENODEV)
goto out;
- }
/* Get another socket */
return 1;
}
3.11-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nicholas Bellinger <[email protected]>
commit 9d86a2befceb06ee83c1a588915e6d6e0abef797 upstream.
This patch addresses a regression bug within ImmediateData=Yes failure
handling that ends up triggering an OOPs within >= v3.10 iscsi-target
code.
The problem occurs when iscsit_process_scsi_cmd() does the call to
target_put_sess_cmd(), and once again in iscsit_get_immediate_data()
that is triggered during two different cases:
- When iscsit_sequence_cmd() returns CMDSN_LOWER_THAN_EXP, for which
the descriptor state will already have been set to ISTATE_REMOVE
by iscsit_sequence_cmd(), and
- When iscsi_cmd->sense_reason is set, for which iscsit_execute_cmd()
will have already called transport_send_check_condition_and_sense()
to queue the exception response.
It changes iscsit_process_scsi_cmd() to drop the early call, and makes
iscsit_get_immediate_data() call target_put_sess_cmd() from a single
location after dumping the immediate data for the failed command.
The regression was initially introduced in commit:
commit 561bf15892375597ee59d473a704a3e634c4f311
Author: Nicholas Bellinger <[email protected]>
Date: Wed Jul 3 03:58:58 2013 -0700
iscsi-target: Fix iscsit_sequence_cmd reject handling for iser
Signed-off-by: Nicholas Bellinger <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/target/iscsi/iscsi_target.c | 9 ++-------
1 file changed, 2 insertions(+), 7 deletions(-)
--- a/drivers/target/iscsi/iscsi_target.c
+++ b/drivers/target/iscsi/iscsi_target.c
@@ -1086,7 +1086,6 @@ int iscsit_process_scsi_cmd(struct iscsi
if (cmd->reject_reason)
return 0;
- target_put_sess_cmd(conn->sess->se_sess, &cmd->se_cmd);
return 1;
}
/*
@@ -1124,14 +1123,10 @@ after_immediate_data:
*/
cmdsn_ret = iscsit_sequence_cmd(cmd->conn, cmd,
(unsigned char *)hdr, hdr->cmdsn);
- if (cmdsn_ret == CMDSN_ERROR_CANNOT_RECOVER) {
+ if (cmdsn_ret == CMDSN_ERROR_CANNOT_RECOVER)
return -1;
- } else if (cmdsn_ret == CMDSN_LOWER_THAN_EXP) {
- target_put_sess_cmd(conn->sess->se_sess, &cmd->se_cmd);
- return 0;
- }
- if (cmd->sense_reason) {
+ if (cmd->sense_reason || cmdsn_ret == CMDSN_LOWER_THAN_EXP) {
int rc;
rc = iscsit_dump_data_payload(cmd->conn,
On Thu, Sep 12, 2013 at 11:18:40AM -0700, Linus Torvalds wrote:
> On Thu, Sep 12, 2013 at 11:17 AM, Linus Torvalds
> <[email protected]> wrote:
> > Your script may be a bit buggered...
>
> Or maybe I should take that as a sign that 3.11 is doing really well?
>
> I'll be optimistic.
Hm, something went wrong here, let me track it down...
greg k-h
On Thu, Sep 12, 2013 at 11:22:40AM -0700, Greg Kroah-Hartman wrote:
> On Thu, Sep 12, 2013 at 11:18:40AM -0700, Linus Torvalds wrote:
> > On Thu, Sep 12, 2013 at 11:17 AM, Linus Torvalds
> > <[email protected]> wrote:
> > > Your script may be a bit buggered...
> >
> > Or maybe I should take that as a sign that 3.11 is doing really well?
> >
> > I'll be optimistic.
>
> Hm, something went wrong here, let me track it down...
Ok, that was my fault, was working off of a 'master' branch in a repo
that expected it to be on the linux-3.11.y branch. Here's the real
pseudo-shortlog below.
And it is short for now, as I've been holding off on applying patches
that are in your tree until 3.12-rc1 comes out. The patches here are
ones that people have pointed out to me that should go in specifically
for various reasons. So yes, I do think 3.11 is doing really well, I
have not heard of anything "major" being wrong with it yet.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <[email protected]>
Linux 3.11.1-rc1
Bing Zhao <[email protected]>
mwifiex: do not create AP and P2P interfaces upon driver loading
Sangjung Woo <[email protected]>
drivers/rtc/rtc-max77686.c: Fix wrong register
John Haxby <[email protected]>
crypto: xor - Check for osxsave as well as avx in crypto/xor
Fabio Estevam <[email protected]>
imx-drm: imx-drm-core: Export imx_drm_encoder_get_mux_id
Fabio Estevam <[email protected]>
ASoC: fsl: Fix module build
Mark Rusk <[email protected]>
drivers/misc/hpilo: Correct panic when an AUX iLO is detected
Lan Tianyu <[email protected]>
ACPI / EC: Add ASUSTEK L4R to quirk list in order to validate ECDT
K. Y. Srinivasan <[email protected]>
Drivers: hv: vmbus: Fix a bug in the handling of channel offers
Wei Hu <[email protected]>
hwmon: (k10temp) Add support for Fam16h (Kabini)
Graham Williams <[email protected]>
usb: acm gadget: Null termintate strings table
Tomas Winkler <[email protected]>
mei: me: fix hardware reset flow
Nicholas Bellinger <[email protected]>
target: Fix se_cmd->state_list leak regression during WRITE failure
Nicholas Bellinger <[email protected]>
iscsi-target: Fix potential NULL pointer in solicited NOPOUT reject
Nicholas Bellinger <[email protected]>
iscsi-target: Fix iscsit_transport reference leak during NP thread reset
Nicholas Bellinger <[email protected]>
iscsi-target: Fix ImmediateData=Yes failure regression in >= v3.10
Nicholas Bellinger <[email protected]>
target: Fix trailing ASCII space usage in INQUIRY vendor+model
-------------
Diffstat:
Documentation/hwmon/k10temp | 1 +
Makefile | 4 ++--
arch/x86/include/asm/xor_avx.h | 4 ++--
drivers/acpi/ec.c | 4 ++++
drivers/hv/channel_mgmt.c | 14 +++++++-------
drivers/hwmon/Kconfig | 4 ++--
drivers/hwmon/k10temp.c | 3 ++-
drivers/misc/hpilo.c | 4 ++--
drivers/misc/mei/hw-me.c | 9 +++------
drivers/net/wireless/mwifiex/main.c | 14 --------------
drivers/rtc/rtc-max77686.c | 4 ++--
drivers/staging/imx-drm/imx-drm-core.c | 1 +
drivers/target/iscsi/iscsi_target.c | 17 ++++++++++-------
drivers/target/iscsi/iscsi_target_login.c | 9 ++++-----
drivers/target/target_core_spc.c | 9 ++++++---
drivers/target/target_core_transport.c | 11 +++++++++++
drivers/usb/gadget/f_acm.c | 1 +
sound/soc/fsl/Kconfig | 4 ++--
sound/soc/fsl/imx-pcm.h | 4 ++--
19 files changed, 64 insertions(+), 57 deletions(-)
Hi
On Thursday 12 September 2013, Greg Kroah-Hartman wrote:
> On Thu, Sep 12, 2013 at 11:22:40AM -0700, Greg Kroah-Hartman wrote:
> > On Thu, Sep 12, 2013 at 11:18:40AM -0700, Linus Torvalds wrote:
> > > On Thu, Sep 12, 2013 at 11:17 AM, Linus Torvalds
> > > <[email protected]> wrote:
> > > > Your script may be a bit buggered...
> > >
> > > Or maybe I should take that as a sign that 3.11 is doing really well?
> > >
> > > I'll be optimistic.
> >
> > Hm, something went wrong here, let me track it down...
>
> Ok, that was my fault, was working off of a 'master' branch in a repo
> that expected it to be on the linux-3.11.y branch. Here's the real
> pseudo-shortlog below.
[…]
This unfortunately affects the linked patch files as well, which are as
empty as the shortlog (compressed zero byte files); the sha256sum are
correct:
$ wget -qO- kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.11.1-rc1.gz | gzip -d
$
$ wget -qO- kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.11.1-rc1.bz2 | bzip2 -d
$
$ wget -qO- kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.11.1-rc1.xz | xz -d
xz: (stdin): File format not recognized
$
Regards
Stefan Lippers-Hollmann
On Thu, Sep 12, 2013 at 09:41:59PM +0000, Stefan Lippers-Hollmann wrote:
> Hi
>
> On Thursday 12 September 2013, Greg Kroah-Hartman wrote:
> > On Thu, Sep 12, 2013 at 11:22:40AM -0700, Greg Kroah-Hartman wrote:
> > > On Thu, Sep 12, 2013 at 11:18:40AM -0700, Linus Torvalds wrote:
> > > > On Thu, Sep 12, 2013 at 11:17 AM, Linus Torvalds
> > > > <[email protected]> wrote:
> > > > > Your script may be a bit buggered...
> > > >
> > > > Or maybe I should take that as a sign that 3.11 is doing really well?
> > > >
> > > > I'll be optimistic.
> > >
> > > Hm, something went wrong here, let me track it down...
> >
> > Ok, that was my fault, was working off of a 'master' branch in a repo
> > that expected it to be on the linux-3.11.y branch. Here's the real
> > pseudo-shortlog below.
> […]
>
> This unfortunately affects the linked patch files as well, which are as
> empty as the shortlog (compressed zero byte files); the sha256sum are
> correct:
>
> $ wget -qO- kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.11.1-rc1.gz | gzip -d
> $
>
> $ wget -qO- kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.11.1-rc1.bz2 | bzip2 -d
> $
>
> $ wget -qO- kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.11.1-rc1.xz | xz -d
> xz: (stdin): File format not recognized
Ah, good catch, I've copied up the patch properly and it should mirror
out soon.
thanks,
greg k-h
On 09/12/2013 11:14 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.11.1 release.
> There are 16 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 Sat Sep 14 18:10:15 UTC 2013.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.11.1-rc1.gz
> and the diffstat can be found below.
>
Test results:
total: 110 pass: 107 skipped: 2 fail: 1
The failure is xtensa:allmodconfig. A patch fixing the problem has been submitted,
but is not yet available upstream.
qemu:
arm, microblaze, mips, mips64, ppc, x86, x86_64 all pass.
sh passed with warning.
qemu:sh is new and only passes because of a patch I had to add to fix qemu,
so don't try it yourself. It also does create a backtrace due to a known
problem for which a patch has been submitted but is not yet available
upstream.
Details are at http://server.roeck-us.net:8010/builders.
Guenter
On Thu, Sep 12, 2013 at 03:37:10PM -0700, Guenter Roeck wrote:
> On 09/12/2013 11:14 AM, Greg Kroah-Hartman wrote:
> >This is the start of the stable review cycle for the 3.11.1 release.
> >There are 16 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 Sat Sep 14 18:10:15 UTC 2013.
> >Anything received after that time might be too late.
> >
> >The whole patch series can be found in one patch at:
> > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.11.1-rc1.gz
> >and the diffstat can be found below.
> >
>
> Test results:
> total: 110 pass: 107 skipped: 2 fail: 1
>
> The failure is xtensa:allmodconfig. A patch fixing the problem has been submitted,
> but is not yet available upstream.
What was skipped?
Anyway, thanks for testing and letting me know.
greg k-h
On 09/12/2013 04:07 PM, Greg Kroah-Hartman wrote:
> On Thu, Sep 12, 2013 at 03:37:10PM -0700, Guenter Roeck wrote:
>> On 09/12/2013 11:14 AM, Greg Kroah-Hartman wrote:
>>> This is the start of the stable review cycle for the 3.11.1 release.
>>> There are 16 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 Sat Sep 14 18:10:15 UTC 2013.
>>> Anything received after that time might be too late.
>>>
>>> The whole patch series can be found in one patch at:
>>> kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.11.1-rc1.gz
>>> and the diffstat can be found below.
>>>
>>
>> Test results:
>> total: 110 pass: 107 skipped: 2 fail: 1
>>
>> The failure is xtensa:allmodconfig. A patch fixing the problem has been submitted,
>> but is not yet available upstream.
>
> What was skipped?
>
Ah, someone noticed :).
Builds are listed as "skipped" if the configuration step fails. Usually
that means that the configuration does not exist, though in rare cases
it may fail for other reasons, which is why I still list it. For 3.11,
skipped builds are arm:ap4evb_defconfig and arm:bonito_defconfig,
both of which have been removed from 3.11.
For qemu tests, skipped means that the test is known to fail with
the affected kernel version, typically because qemu and that kernel
version don't like each other, so I don't bother trying.
Guenter
On 09/12/2013 12:27 PM, Greg Kroah-Hartman wrote:
> On Thu, Sep 12, 2013 at 11:22:40AM -0700, Greg Kroah-Hartman wrote:
>> On Thu, Sep 12, 2013 at 11:18:40AM -0700, Linus Torvalds wrote:
>>> On Thu, Sep 12, 2013 at 11:17 AM, Linus Torvalds
>>> <[email protected]> wrote:
>>>> Your script may be a bit buggered...
>>>
>>> Or maybe I should take that as a sign that 3.11 is doing really well?
>>>
>>> I'll be optimistic.
>>
>> Hm, something went wrong here, let me track it down...
>
> Ok, that was my fault, was working off of a 'master' branch in a repo
> that expected it to be on the linux-3.11.y branch. Here's the real
> pseudo-shortlog below.
>
> And it is short for now, as I've been holding off on applying patches
> that are in your tree until 3.12-rc1 comes out. The patches here are
> ones that people have pointed out to me that should go in specifically
> for various reasons. So yes, I do think 3.11 is doing really well, I
> have not heard of anything "major" being wrong with it yet.
>
> thanks,
>
> greg k-h
>
>
3.11.1-rc1 applied cleanly to 3.11
Compiled and booted on the following systems:
Samsung Series 9 900X4C Intel Corei5
HP ProBook 6475b AMD A10-4600M APU with Radeon(tm) HD Graphics
dmesgs look good. No regressions compared to the previous dmesgs for
this release. dmesg emerg, crit, alert, err are clean. No regressions in
warn.
Cross-compile testing: HP Compaq dc7700 SFF desktop: x86-64 Intel Core-i2:
Cross-compile tests results:
alpha: defconfig passed
arm: defconfig passed
arm64: defconfig passed
blackfin: defconfig passed
c6x: defconfig passed
mips: defconfig passed
mipsel: defconfig passed
powerpc: wii_defconfig passed
sh: defconfig passed
sparc: defconfig passed
tile: tilegx_defconfig passed
-- Shuah
--
Shuah Khan
Senior Linux Kernel Developer - Open Source Group
Samsung Research America(Silicon Valley)
[email protected] | (970) 672-0658
On Fri, Sep 13, 2013 at 04:59:29PM -0600, Shuah Khan wrote:
> On 09/12/2013 12:27 PM, Greg Kroah-Hartman wrote:
> >On Thu, Sep 12, 2013 at 11:22:40AM -0700, Greg Kroah-Hartman wrote:
> >>On Thu, Sep 12, 2013 at 11:18:40AM -0700, Linus Torvalds wrote:
> >>>On Thu, Sep 12, 2013 at 11:17 AM, Linus Torvalds
> >>><[email protected]> wrote:
> >>>>Your script may be a bit buggered...
> >>>
> >>>Or maybe I should take that as a sign that 3.11 is doing really well?
> >>>
> >>>I'll be optimistic.
> >>
> >>Hm, something went wrong here, let me track it down...
> >
> >Ok, that was my fault, was working off of a 'master' branch in a repo
> >that expected it to be on the linux-3.11.y branch. Here's the real
> >pseudo-shortlog below.
> >
> >And it is short for now, as I've been holding off on applying patches
> >that are in your tree until 3.12-rc1 comes out. The patches here are
> >ones that people have pointed out to me that should go in specifically
> >for various reasons. So yes, I do think 3.11 is doing really well, I
> >have not heard of anything "major" being wrong with it yet.
> >
> >thanks,
> >
> >greg k-h
> >
> >
>
> 3.11.1-rc1 applied cleanly to 3.11
>
> Compiled and booted on the following systems:
>
> Samsung Series 9 900X4C Intel Corei5
> HP ProBook 6475b AMD A10-4600M APU with Radeon(tm) HD Graphics
>
> dmesgs look good. No regressions compared to the previous dmesgs for
> this release. dmesg emerg, crit, alert, err are clean. No
> regressions in warn.
Great, thanks for testing and letting me know.
greg k-h