Skip to contentSkip to conversation

3.10.11-stable review

PATCH In review Greg Kroah-Hartman 4 participants 44 messages Sep 5, 2013 – Sep 6, 2013

Subsystems (42)
lore
Share & tools
lore

Greg Kroah-Hartman

author maintainer
#0 lore raw

cover 3.10.11-stable review

This is the start of the stable review cycle for the 3.10.11 release. There are 36 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 7 20:26:25 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.10.11-rc1.gz

and the diffstat can be found below.

thanks,

greg k-h

-------------
Pseudo-Shortlog of commits:

Greg Kroah-Hartman <[email protected]>

    Linux 3.10.11-rc1

David Jander <[email protected]>
regmap: rbtree: Fix overlapping rbnodes.

Fabio Estevam <[email protected]>
imx-drm: imx-drm-core: Export imx_drm_encoder_get_mux_id

Julien Grall <[email protected]>
xen/arm: missing put_cpu in xen_percpu_init

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

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]>
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

Stanislaw Gruszka <[email protected]>
iwl4965: fix rfkill set state regression

Felix Fietkau <[email protected]>
mac80211: add a flag to indicate CCK support for HT clients

Johannes Berg <[email protected]>
mac80211: add missing channel context release

Sujith Manoharan <[email protected]>
ath9k: Enable PLL fix only for AR9340/AR9330

Helmut Schaa <[email protected]>
ath9k_htc: Restore skb headroom when returning skb to mac80211

Yinghai Lu <[email protected]>
x86/mm: Fix boot crash with DEBUG_PAGE_ALLOC=y and more than 512G RAM

Trond Myklebust <[email protected]>
SUNRPC: Fix memory corruption issue on 32-bit highmem systems

Imre Deak <[email protected]>
drm/i915: ivb: fix edp voltage swing reg val

Jakob Bornecrantz <[email protected]>
drm/vmwgfx: Split GMR2_REMAP commands if they are to large

Tejun Heo <[email protected]>
workqueue: cond_resched() after processing each work item

Andrey Vagin <[email protected]>
memcg: check that kmem_cache has memcg_params before accessing it

Russ Anderson <[email protected]>
drivers/base/memory.c: fix show_mem_removable() to handle missing sections

Svenning Soerensen <[email protected]>
IPC: bugfix for msgrcv with msgtyp < 0

Nathan Zimmer <[email protected]>
timer_list: correct the iterator for timer_list

Kevin Hilman <[email protected]>
regmap: Add another missing header for !CONFIG_REGMAP stubs

Hans Verkuil <[email protected]>

    SCSI: pm80xx: fix Adaptec 71605H hang

Eugene Surovegin <[email protected]>
powerpc/hvsi: Increase handshake timeout from 200ms to 400ms.

Benjamin Herrenschmidt <[email protected]>
powerpc: Don't Oops when accessing /proc/powerpc/lparcfg without hypervisor

Paul Mackerras <[email protected]>
powerpc: Work around gcc miscompilation of __pa() on 64-bit

Takashi Iwai <[email protected]>
ALSA: opti9xx: Fix conflicting driver object name

Takashi Iwai <[email protected]>
ALSA: hda - Add inverted digital mic fixup for Acer Aspire One

Takashi Iwai <[email protected]>
ALSA: hda - Fix NULL dereference with CONFIG_SND_DYNAMIC_MINORS=n

Dave Kleikamp <[email protected]>
jfs: fix readdir cookie incompatibility with NFSv4

Ben Skeggs <[email protected]>
drm/nouveau/mc: fix race condition between constructor and request_irq()

-------------

Diffstat:

 Documentation/hwmon/k10temp                      |  1 +
 Makefile                                         |  4 +-
 arch/arm/xen/enlighten.c                         |  1 +
 arch/powerpc/Kconfig                             |  1 +
 arch/powerpc/include/asm/page.h                  | 10 ++++
 arch/powerpc/kernel/lparcfg.c                    | 22 ++++-----
 arch/x86/mm/init.c                               |  4 +-
 drivers/acpi/ec.c                                |  4 ++
 drivers/base/memory.c                            |  2 +
 drivers/base/regmap/regcache-rbtree.c            |  2 +-
 drivers/gpu/drm/i915/i915_reg.h                  |  2 +-
 drivers/gpu/drm/nouveau/core/include/subdev/mc.h |  7 +--
 drivers/gpu/drm/nouveau/core/subdev/mc/base.c    |  6 ++-
 drivers/gpu/drm/nouveau/core/subdev/mc/nv04.c    |  3 +-
 drivers/gpu/drm/nouveau/core/subdev/mc/nv44.c    |  3 +-
 drivers/gpu/drm/nouveau/core/subdev/mc/nv50.c    |  3 +-
 drivers/gpu/drm/nouveau/core/subdev/mc/nv98.c    |  3 +-
 drivers/gpu/drm/nouveau/core/subdev/mc/nvc0.c    |  3 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_gmr.c              | 58 ++++++++++++++++--------
 drivers/hwmon/Kconfig                            |  4 +-
 drivers/hwmon/k10temp.c                          |  3 +-
 drivers/misc/hpilo.c                             |  4 +-
 drivers/misc/mei/hw-me.c                         |  8 ++--
 drivers/net/wireless/ath/ath9k/htc_drv_txrx.c    | 10 ++++
 drivers/net/wireless/ath/ath9k/init.c            |  3 +-
 drivers/net/wireless/ath/ath9k/main.c            |  3 +-
 drivers/net/wireless/ath/carl9170/main.c         |  3 +-
 drivers/net/wireless/iwlegacy/4965-mac.c         |  2 +-
 drivers/net/wireless/rt2x00/rt2800lib.c          |  3 +-
 drivers/scsi/pm8001/pm8001_hwi.c                 |  4 +-
 drivers/scsi/pm8001/pm80xx_hwi.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/tty/hvc/hvsi_lib.c                       |  4 +-
 drivers/usb/gadget/f_acm.c                       |  1 +
 fs/jfs/jfs_dtree.c                               | 31 +++++++++----
 include/linux/regmap.h                           |  1 +
 include/net/mac80211.h                           |  1 +
 ipc/msg.c                                        |  5 +-
 kernel/time/timer_list.c                         | 41 ++++++++++-------
 kernel/workqueue.c                               |  9 ++++
 mm/slab.h                                        |  2 +
 net/mac80211/ibss.c                              |  1 +
 net/mac80211/rc80211_minstrel_ht.c               |  3 ++
 net/sunrpc/xdr.c                                 |  9 ++--
 sound/isa/opti9xx/opti92x-ad1848.c               |  8 +---
 sound/pci/hda/patch_hdmi.c                       |  3 ++
 sound/pci/hda/patch_realtek.c                    |  1 +
 50 files changed, 221 insertions(+), 125 deletions(-)
author maintainer
#1 lore raw

PATCH 1/36 drm/nouveau/mc: fix race condition between constructor and request_irq()

3.10-stable review patch. If anyone has any objections, please let me know.

------------------

From: Ben Skeggs <[email protected]>

commit 6ff8c76a566f823d796359a6c1d76b7668f1e34d upstream.

---
 drivers/gpu/drm/nouveau/core/include/subdev/mc.h |    7 ++++---
 drivers/gpu/drm/nouveau/core/subdev/mc/base.c    |    6 +++++-
 drivers/gpu/drm/nouveau/core/subdev/mc/nv04.c    |    3 +--
 drivers/gpu/drm/nouveau/core/subdev/mc/nv44.c    |    3 +--
 drivers/gpu/drm/nouveau/core/subdev/mc/nv50.c    |    3 +--
 drivers/gpu/drm/nouveau/core/subdev/mc/nv98.c    |    3 +--
 drivers/gpu/drm/nouveau/core/subdev/mc/nvc0.c    |    3 +--
 7 files changed, 14 insertions(+), 14 deletions(-)
drivers/gpu/drm/nouveau/core/include/subdev/mc.h +4 -3
@@ -20,8 +20,8 @@ nouveau_mc(void *obj)
 	return (void *)nv_device(obj)->subdev[NVDEV_SUBDEV_MC];
 }
 
-#define nouveau_mc_create(p,e,o,d)                                             \
-	nouveau_mc_create_((p), (e), (o), sizeof(**d), (void **)d)
+#define nouveau_mc_create(p,e,o,m,d)                                           \
+	nouveau_mc_create_((p), (e), (o), (m), sizeof(**d), (void **)d)
 #define nouveau_mc_destroy(p) ({                                               \
 	struct nouveau_mc *pmc = (p); _nouveau_mc_dtor(nv_object(pmc));        \
 })
@@ -33,7 +33,8 @@ nouveau_mc(void *obj)
 })
 
 int  nouveau_mc_create_(struct nouveau_object *, struct nouveau_object *,
-			struct nouveau_oclass *, int, void **);
+			struct nouveau_oclass *, const struct nouveau_mc_intr *,
+			int, void **);
 void _nouveau_mc_dtor(struct nouveau_object *);
 int  _nouveau_mc_init(struct nouveau_object *);
 int  _nouveau_mc_fini(struct nouveau_object *, bool);
drivers/gpu/drm/nouveau/core/subdev/mc/base.c +5 -1
@@ -80,7 +80,9 @@ _nouveau_mc_dtor(struct nouveau_object *
 
 int
 nouveau_mc_create_(struct nouveau_object *parent, struct nouveau_object *engine,
-		   struct nouveau_oclass *oclass, int length, void **pobject)
+		   struct nouveau_oclass *oclass,
+		   const struct nouveau_mc_intr *intr_map,
+		   int length, void **pobject)
 {
 	struct nouveau_device *device = nv_device(parent);
 	struct nouveau_mc *pmc;
@@ -92,6 +94,8 @@ nouveau_mc_create_(struct nouveau_object
 	if (ret)
 		return ret;
 
+	pmc->intr_map = intr_map;
+
 	ret = request_irq(device->pdev->irq, nouveau_mc_intr,
 			  IRQF_SHARED, "nouveau", pmc);
 	if (ret < 0)
drivers/gpu/drm/nouveau/core/subdev/mc/nv04.c +1 -2
@@ -50,12 +50,11 @@ nv04_mc_ctor(struct nouveau_object *pare
 	struct nv04_mc_priv *priv;
 	int ret;
 
-	ret = nouveau_mc_create(parent, engine, oclass, &priv);
+	ret = nouveau_mc_create(parent, engine, oclass, nv04_mc_intr, &priv);
 	*pobject = nv_object(priv);
 	if (ret)
 		return ret;
 
-	priv->base.intr_map = nv04_mc_intr;
 	return 0;
 }
 
drivers/gpu/drm/nouveau/core/subdev/mc/nv44.c +1 -2
@@ -36,12 +36,11 @@ nv44_mc_ctor(struct nouveau_object *pare
 	struct nv44_mc_priv *priv;
 	int ret;
 
-	ret = nouveau_mc_create(parent, engine, oclass, &priv);
+	ret = nouveau_mc_create(parent, engine, oclass, nv04_mc_intr, &priv);
 	*pobject = nv_object(priv);
 	if (ret)
 		return ret;
 
-	priv->base.intr_map = nv04_mc_intr;
 	return 0;
 }
 
drivers/gpu/drm/nouveau/core/subdev/mc/nv50.c +1 -2
@@ -52,12 +52,11 @@ nv50_mc_ctor(struct nouveau_object *pare
 	struct nv50_mc_priv *priv;
 	int ret;
 
-	ret = nouveau_mc_create(parent, engine, oclass, &priv);
+	ret = nouveau_mc_create(parent, engine, oclass, nv50_mc_intr, &priv);
 	*pobject = nv_object(priv);
 	if (ret)
 		return ret;
 
-	priv->base.intr_map = nv50_mc_intr;
 	return 0;
 }
 
drivers/gpu/drm/nouveau/core/subdev/mc/nv98.c +1 -2
@@ -54,12 +54,11 @@ nv98_mc_ctor(struct nouveau_object *pare
 	struct nv98_mc_priv *priv;
 	int ret;
 
-	ret = nouveau_mc_create(parent, engine, oclass, &priv);
+	ret = nouveau_mc_create(parent, engine, oclass, nv98_mc_intr, &priv);
 	*pobject = nv_object(priv);
 	if (ret)
 		return ret;
 
-	priv->base.intr_map = nv98_mc_intr;
 	return 0;
 }
 
drivers/gpu/drm/nouveau/core/subdev/mc/nvc0.c +1 -2
@@ -56,12 +56,11 @@ nvc0_mc_ctor(struct nouveau_object *pare
 	struct nvc0_mc_priv *priv;
 	int ret;
 
-	ret = nouveau_mc_create(parent, engine, oclass, &priv);
+	ret = nouveau_mc_create(parent, engine, oclass, nvc0_mc_intr, &priv);
 	*pobject = nv_object(priv);
 	if (ret)
 		return ret;
 
-	priv->base.intr_map = nvc0_mc_intr;
 	return 0;
 }
 
author maintainer
#2 lore raw

PATCH 2/36 jfs: fix readdir cookie incompatibility with NFSv4

In reply to Greg Kroah-Hartman

3.10-stable review patch. If anyone has any objections, please let me know.

------------------

From: Dave Kleikamp <[email protected]>

commit 44512449c0ab368889dd13ae0031fba74ee7e1d2 upstream.

NFSv4 reserves readdir cookie values 0-2 for special entries (. and ..), but jfs allows a value of 2 for a non-special entry. This incompatibility can result in the nfs client reporting a readdir loop.

This patch doesn't change the value stored internally, but adds one to the value exposed to the iterate method.

[bwh: Backported to 3.2:
- Adjust context
- s/ctx->pos/filp->f_pos/]

---
 fs/jfs/jfs_dtree.c |   31 +++++++++++++++++++++++--------
 1 file changed, 23 insertions(+), 8 deletions(-)
fs/jfs/jfs_dtree.c +23 -8
@@ -3047,6 +3047,14 @@ int jfs_readdir(struct file *filp, void
 
 		dir_index = (u32) filp->f_pos;
 
+		/*
+		 * NFSv4 reserves cookies 1 and 2 for . and .. so we add
+		 * the value we return to the vfs is one greater than the
+		 * one we use internally.
+		 */
+		if (dir_index)
+			dir_index--;
+
 		if (dir_index > 1) {
 			struct dir_table_slot dirtab_slot;
 
@@ -3086,7 +3094,7 @@ int jfs_readdir(struct file *filp, void
 			if (p->header.flag & BT_INTERNAL) {
 				jfs_err("jfs_readdir: bad index table");
 				DT_PUTPAGE(mp);
-				filp->f_pos = -1;
+				filp->f_pos = DIREND;
 				return 0;
 			}
 		} else {
@@ -3094,7 +3102,7 @@ int jfs_readdir(struct file *filp, void
 				/*
 				 * self "."
 				 */
-				filp->f_pos = 0;
+				filp->f_pos = 1;
 				if (filldir(dirent, ".", 1, 0, ip->i_ino,
 					    DT_DIR))
 					return 0;
@@ -3102,7 +3110,7 @@ int jfs_readdir(struct file *filp, void
 			/*
 			 * parent ".."
 			 */
-			filp->f_pos = 1;
+			filp->f_pos = 2;
 			if (filldir(dirent, "..", 2, 1, PARENT(ip), DT_DIR))
 				return 0;
 
@@ -3123,24 +3131,25 @@ int jfs_readdir(struct file *filp, void
 		/*
 		 * Legacy filesystem - OS/2 & Linux JFS < 0.3.6
 		 *
-		 * pn = index = 0:	First entry "."
-		 * pn = 0; index = 1:	Second entry ".."
+		 * pn = 0; index = 1:	First entry "."
+		 * pn = 0; index = 2:	Second entry ".."
 		 * pn > 0:		Real entries, pn=1 -> leftmost page
 		 * pn = index = -1:	No more entries
 		 */
 		dtpos = filp->f_pos;
-		if (dtpos == 0) {
+		if (dtpos < 2) {
 			/* build "." entry */
 
+			filp->f_pos = 1;
 			if (filldir(dirent, ".", 1, filp->f_pos, ip->i_ino,
 				    DT_DIR))
 				return 0;
-			dtoffset->index = 1;
+			dtoffset->index = 2;
 			filp->f_pos = dtpos;
 		}
 
 		if (dtoffset->pn == 0) {
-			if (dtoffset->index == 1) {
+			if (dtoffset->index == 2) {
 				/* build ".." entry */
 
 				if (filldir(dirent, "..", 2, filp->f_pos,
@@ -3233,6 +3242,12 @@ int jfs_readdir(struct file *filp, void
 					}
 					jfs_dirent->position = unique_pos++;
 				}
+				/*
+				 * We add 1 to the index because we may
+				 * use a value of 2 internally, and NFSv4
+				 * doesn't like that.
+				 */
+				jfs_dirent->position++;
 			} else {
 				jfs_dirent->position = dtpos;
 				len = min(d_namleft, DTLHDRDATALEN_LEGACY);
author maintainer
#3 lore raw

PATCH 3/36 ALSA: hda - Fix NULL dereference with CONFIG_SND_DYNAMIC_MINORS=n

In reply to Greg Kroah-Hartman

3.10-stable review patch. If anyone has any objections, please let me know.

------------------

From: Takashi Iwai <[email protected]>

commit 2ca320e294a738c9134a71b5029de05edbfc7aad upstream.

Without the dynamic minor assignment, HDMI codec may have less PCM instances than the number of pins, which eventually leads to Oops.

---
 sound/pci/hda/patch_hdmi.c |    3 +++
 1 file changed, 3 insertions(+)
sound/pci/hda/patch_hdmi.c +3 -0
@@ -1715,6 +1715,9 @@ static int generic_hdmi_build_controls(s
 		struct snd_pcm_chmap *chmap;
 		struct snd_kcontrol *kctl;
 		int i;
+
+		if (!codec->pcm_info[pin_idx].pcm)
+			break;
 		err = snd_pcm_add_chmap_ctls(codec->pcm_info[pin_idx].pcm,
 					     SNDRV_PCM_STREAM_PLAYBACK,
 					     NULL, 0, pin_idx, &chmap);
author maintainer
#4 lore raw

PATCH 4/36 ALSA: hda - Add inverted digital mic fixup for Acer Aspire One

In reply to Greg Kroah-Hartman

3.10-stable review patch. If anyone has any objections, please let me know.

------------------

From: Takashi Iwai <[email protected]>

commit d3d3835ce919438c00c5d1270d6f9d6ffea59d03 upstream.

Yet another entry, just use the existing fixup for this machine, too.

---
 sound/pci/hda/patch_realtek.c |    1 +
 1 file changed, 1 insertion(+)
sound/pci/hda/patch_realtek.c +1 -0
@@ -4207,6 +4207,7 @@ static const struct hda_fixup alc662_fix
 
 static const struct snd_pci_quirk alc662_fixup_tbl[] = {
 	SND_PCI_QUIRK(0x1019, 0x9087, "ECS", ALC662_FIXUP_ASUS_MODE2),
+	SND_PCI_QUIRK(0x1025, 0x022f, "Acer Aspire One", ALC662_FIXUP_INV_DMIC),
 	SND_PCI_QUIRK(0x1025, 0x0308, "Acer Aspire 8942G", ALC662_FIXUP_ASPIRE),
 	SND_PCI_QUIRK(0x1025, 0x031c, "Gateway NV79", ALC662_FIXUP_SKU_IGNORE),
 	SND_PCI_QUIRK(0x1025, 0x0349, "eMachines eM250", ALC662_FIXUP_INV_DMIC),
author maintainer
#5 lore raw

PATCH 5/36 ALSA: opti9xx: Fix conflicting driver object name

In reply to Greg Kroah-Hartman

3.10-stable review patch. If anyone has any objections, please let me know.

------------------

From: Takashi Iwai <[email protected]>

commit fb615499f0ad28ed74201c1cdfddf9e64e205424 upstream.

The recent commit to delay the release of kobject triggered NULL dereferences of opti9xx drivers. The cause is that all snd-opti92x-ad1848, snd-opti92x-cs4231 and snd-opti93x drivers register the PnP card driver with the very same name, and also snd-opti92x-ad1848 and -cs4231 drivers register the ISA driver with the same name, too. When these drivers are built in, quick "register-release-and-re-register" actions occur, and this results in Oops because of the same name is assigned to the kobject.

The fix is simply to assign individual names. As a bonus, by using KBUILD_MODNAME, the patch reduces more lines than it adds.

The fix is based on the suggestion by Russell King.

---
 sound/isa/opti9xx/opti92x-ad1848.c |    8 ++------
 1 file changed, 2 insertions(+), 6 deletions(-)
sound/isa/opti9xx/opti92x-ad1848.c +2 -6
@@ -173,11 +173,7 @@ MODULE_DEVICE_TABLE(pnp_card, snd_opti9x
 
 #endif	/* CONFIG_PNP */
 
-#ifdef OPTi93X
-#define DEV_NAME "opti93x"
-#else
-#define DEV_NAME "opti92x"
-#endif
+#define DEV_NAME KBUILD_MODNAME
 
 static char * snd_opti9xx_names[] = {
 	"unknown",
@@ -1168,7 +1164,7 @@ static int snd_opti9xx_pnp_resume(struct
 
 static struct pnp_card_driver opti9xx_pnpc_driver = {
 	.flags		= PNP_DRIVER_RES_DISABLE,
-	.name		= "opti9xx",
+	.name		= DEV_NAME,
 	.id_table	= snd_opti9xx_pnpids,
 	.probe		= snd_opti9xx_pnp_probe,
 	.remove		= snd_opti9xx_pnp_remove,
author maintainer
#6 lore raw

PATCH 6/36 powerpc: Work around gcc miscompilation of __pa() on 64-bit

In reply to Greg Kroah-Hartman

3.10-stable review patch. If anyone has any objections, please let me know.

------------------

From: Paul Mackerras <[email protected]>

commit bdbc29c19b2633b1d9c52638fb732bcde7a2031a upstream.

On 64-bit, __pa(&static_var) gets miscompiled by recent versions of gcc as something like:

        addis 3,2,.LANCHOR1+4611686018427387904@toc@ha
        addi 3,3,.LANCHOR1+4611686018427387904@toc@l

This ends up effectively ignoring the offset, since its bottom 32 bits are zero, and means that the result of __pa() still has 0xC in the top nibble. This happens with gcc 4.8.1, at least.

To work around this, for 64-bit we make __pa() use an AND operator, and for symmetry, we make __va() use an OR operator. Using an AND operator rather than a subtraction ends up with slightly shorter code since it can be done with a single clrldi instruction, whereas it takes three instructions to form the constant (-PAGE_OFFSET) and add it on. (Note that MEMORY_START is always 0 on 64-bit.)

---
 arch/powerpc/Kconfig            |    1 +
 arch/powerpc/include/asm/page.h |   10 ++++++++++
 2 files changed, 11 insertions(+)
arch/powerpc/Kconfig +1 -0
@@ -986,6 +986,7 @@ config RELOCATABLE
 	  must live at a different physical address than the primary
 	  kernel.
 
+# This value must have zeroes in the bottom 60 bits otherwise lots will break
 config PAGE_OFFSET
 	hex
 	default "0xc000000000000000"
arch/powerpc/include/asm/page.h +10 -0
@@ -211,9 +211,19 @@ extern long long virt_phys_offset;
 #define __va(x) ((void *)(unsigned long)((phys_addr_t)(x) + VIRT_PHYS_OFFSET))
 #define __pa(x) ((unsigned long)(x) - VIRT_PHYS_OFFSET)
 #else
+#ifdef CONFIG_PPC64
+/*
+ * gcc miscompiles (unsigned long)(&static_var) - PAGE_OFFSET
+ * with -mcmodel=medium, so we use & and | instead of - and + on 64-bit.
+ */
+#define __va(x) ((void *)(unsigned long)((phys_addr_t)(x) | PAGE_OFFSET))
+#define __pa(x) ((unsigned long)(x) & 0x0fffffffffffffffUL)
+
+#else /* 32-bit, non book E */
 #define __va(x) ((void *)(unsigned long)((phys_addr_t)(x) + PAGE_OFFSET - MEMORY_START))
 #define __pa(x) ((unsigned long)(x) - PAGE_OFFSET + MEMORY_START)
 #endif
+#endif
 
 /*
  * Unfortunately the PLT is in the BSS in the PPC32 ELF ABI,
author maintainer
#7 lore raw

PATCH 7/36 powerpc: Dont Oops when accessing /proc/powerpc/lparcfg without hypervisor

In reply to Greg Kroah-Hartman

3.10-stable review patch. If anyone has any objections, please let me know.

------------------

From: Benjamin Herrenschmidt <[email protected]>

commit f5f6cbb61610b7bf9d9d96db9c3979d62a424bab upstream.

/proc/powerpc/lparcfg is an ancient facility (though still actively used) which allows access to some informations relative to the partition when running underneath a PAPR compliant hypervisor.

It makes no sense on non-pseries machines. However, currently, not only can it be created on these if the kernel has pseries support, but accessing it on such a machine will crash due to trying to do hypervisor calls.

In fact, it should also not do HV calls on older pseries that didn't have an hypervisor either.

Finally, it has the plumbing to be a module but is a "bool" Kconfig option.

This fixes the whole lot by turning it into a machine_device_initcall that is only created on pseries, and adding the necessary hypervisor check before calling the H_GET_EM_PARMS hypercall

---
 arch/powerpc/kernel/lparcfg.c |   22 +++++++++-------------
 1 file changed, 9 insertions(+), 13 deletions(-)
arch/powerpc/kernel/lparcfg.c +9 -13
@@ -35,7 +35,13 @@
 #include <asm/vdso_datapage.h>
 #include <asm/vio.h>
 #include <asm/mmu.h>
+#include <asm/machdep.h>
 
+
+/*
+ * This isn't a module but we expose that to userspace
+ * via /proc so leave the definitions here
+ */
 #define MODULE_VERS "1.9"
 #define MODULE_NAME "lparcfg"
 
@@ -418,7 +424,8 @@ static void parse_em_data(struct seq_fil
 {
 	unsigned long retbuf[PLPAR_HCALL_BUFSIZE];
 
-	if (plpar_hcall(H_GET_EM_PARMS, retbuf) == H_SUCCESS)
+	if (firmware_has_feature(FW_FEATURE_LPAR) &&
+	    plpar_hcall(H_GET_EM_PARMS, retbuf) == H_SUCCESS)
 		seq_printf(m, "power_mode_data=%016lx\n", retbuf[0]);
 }
 
@@ -677,7 +684,6 @@ static int lparcfg_open(struct inode *in
 }
 
 static const struct file_operations lparcfg_fops = {
-	.owner		= THIS_MODULE,
 	.read		= seq_read,
 	.write		= lparcfg_write,
 	.open		= lparcfg_open,
@@ -699,14 +705,4 @@ static int __init lparcfg_init(void)
 	}
 	return 0;
 }
-
-static void __exit lparcfg_cleanup(void)
-{
-	remove_proc_subtree("powerpc/lparcfg", NULL);
-}
-
-module_init(lparcfg_init);
-module_exit(lparcfg_cleanup);
-MODULE_DESCRIPTION("Interface for LPAR configuration data");
-MODULE_AUTHOR("Dave Engebretsen");
-MODULE_LICENSE("GPL");
+machine_device_initcall(pseries, lparcfg_init);
author maintainer
#8 lore raw

PATCH 8/36 powerpc/hvsi: Increase handshake timeout from 200ms to 400ms.

In reply to Greg Kroah-Hartman

3.10-stable review patch. If anyone has any objections, please let me know.

------------------

From: Eugene Surovegin <[email protected]>

commit d220980b701d838560a70de691b53be007e99e78 upstream.

This solves a problem observed in kexec'ed kernel where 200ms timeout is too short and bootconsole fails to initialize. Console did eventually become workable but much later into the boot process.

Observed timeout was around 260ms, but I decided to make it a little bigger for more reliability.

This has been tested on Power7 machine with Petitboot as a primary bootloader and PowerNV firmware.

---
 drivers/tty/hvc/hvsi_lib.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/tty/hvc/hvsi_lib.c +2 -2
@@ -341,8 +341,8 @@ void hvsilib_establish(struct hvsi_priv
 
 	pr_devel("HVSI@%x:   ... waiting handshake\n", pv->termno);
 
-	/* Try for up to 200s */
-	for (timeout = 0; timeout < 20; timeout++) {
+	/* Try for up to 400ms */
+	for (timeout = 0; timeout < 40; timeout++) {
 		if (pv->established)
 			goto established;
 		if (!hvsi_get_packet(pv))
author maintainer
#9 lore raw

PATCH 9/36 SCSI: pm80xx: fix Adaptec 71605H hang

In reply to Greg Kroah-Hartman

3.10-stable review patch. If anyone has any objections, please let me know.

------------------

From: Hans Verkuil <[email protected]>

commit 9504a923924d663e1953f872f0a828e6454a6cfc upstream.

The IO command size is 128 bytes for these new controllers as opposed to 64 for the old 8001 controller.

The Adaptec out-of-tree driver did this correctly. After comparing the two this turned out to be the crucial difference.

So don't hardcode the IO command size, instead use pm8001_ha->iomb_size as that is the correct value for both old and new controllers.

---
 drivers/scsi/pm8001/pm8001_hwi.c |    4 ++--
 drivers/scsi/pm8001/pm80xx_hwi.c |    4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)
drivers/scsi/pm8001/pm8001_hwi.c +2 -2
@@ -221,7 +221,7 @@ static void init_default_table_values(st
 	pm8001_ha->main_cfg_tbl.pm8001_tbl.fatal_err_interrupt		= 0x01;
 	for (i = 0; i < PM8001_MAX_INB_NUM; i++) {
 		pm8001_ha->inbnd_q_tbl[i].element_pri_size_cnt	=
-			PM8001_MPI_QUEUE | (64 << 16) | (0x00<<30);
+			PM8001_MPI_QUEUE | (pm8001_ha->iomb_size << 16) | (0x00<<30);
 		pm8001_ha->inbnd_q_tbl[i].upper_base_addr	=
 			pm8001_ha->memoryMap.region[IB + i].phys_addr_hi;
 		pm8001_ha->inbnd_q_tbl[i].lower_base_addr	=
@@ -247,7 +247,7 @@ static void init_default_table_values(st
 	}
 	for (i = 0; i < PM8001_MAX_OUTB_NUM; i++) {
 		pm8001_ha->outbnd_q_tbl[i].element_size_cnt	=
-			PM8001_MPI_QUEUE | (64 << 16) | (0x01<<30);
+			PM8001_MPI_QUEUE | (pm8001_ha->iomb_size << 16) | (0x01<<30);
 		pm8001_ha->outbnd_q_tbl[i].upper_base_addr	=
 			pm8001_ha->memoryMap.region[OB + i].phys_addr_hi;
 		pm8001_ha->outbnd_q_tbl[i].lower_base_addr	=
drivers/scsi/pm8001/pm80xx_hwi.c +2 -2
@@ -275,7 +275,7 @@ static void init_default_table_values(st
 
 	for (i = 0; i < PM8001_MAX_SPCV_INB_NUM; i++) {
 		pm8001_ha->inbnd_q_tbl[i].element_pri_size_cnt	=
-			PM8001_MPI_QUEUE | (64 << 16) | (0x00<<30);
+			PM8001_MPI_QUEUE | (pm8001_ha->iomb_size << 16) | (0x00<<30);
 		pm8001_ha->inbnd_q_tbl[i].upper_base_addr	=
 			pm8001_ha->memoryMap.region[IB + i].phys_addr_hi;
 		pm8001_ha->inbnd_q_tbl[i].lower_base_addr	=
@@ -301,7 +301,7 @@ static void init_default_table_values(st
 	}
 	for (i = 0; i < PM8001_MAX_SPCV_OUTB_NUM; i++) {
 		pm8001_ha->outbnd_q_tbl[i].element_size_cnt	=
-			PM8001_MPI_QUEUE | (64 << 16) | (0x01<<30);
+			PM8001_MPI_QUEUE | (pm8001_ha->iomb_size << 16) | (0x01<<30);
 		pm8001_ha->outbnd_q_tbl[i].upper_base_addr	=
 			pm8001_ha->memoryMap.region[OB + i].phys_addr_hi;
 		pm8001_ha->outbnd_q_tbl[i].lower_base_addr	=
author maintainer
#10 lore raw

PATCH 10/36 regmap: Add another missing header for !CONFIG_REGMAP stubs

In reply to Greg Kroah-Hartman

3.10-stable review patch. If anyone has any objections, please let me know.

------------------

From: Kevin Hilman <[email protected]>

commit 3f0fa9a808f98fa10a18ba2a73f13d65fda990fb upstream.

The use of WARN_ON() needs the definitions from bug.h, without it you can get:

include/linux/regmap.h: In function 'regmap_write':
include/linux/regmap.h:525:2: error: implicit declaration of function 'WARN_ONCE' [-Werror=implicit-function-declaration]

---
 include/linux/regmap.h |    1 +
 1 file changed, 1 insertion(+)
include/linux/regmap.h +1 -0
@@ -16,6 +16,7 @@
 #include <linux/list.h>
 #include <linux/rbtree.h>
 #include <linux/err.h>
+#include <linux/bug.h>
 
 struct module;
 struct device;
author maintainer
#11 lore raw

PATCH 11/36 timer_list: correct the iterator for timer_list

In reply to Greg Kroah-Hartman

3.10-stable review patch. If anyone has any objections, please let me know.

------------------

From: Nathan Zimmer <[email protected]>

commit 84a78a6504f5c5394a8e558702e5b54131f01d14 upstream.

Correct an issue with /proc/timer_list reported by Holger.

When reading from the proc file with a sufficiently small buffer, 2k so not really that small, there was one could get hung trying to read the file a chunk at a time.

The timer_list_start function failed to account for the possibility that the offset was adjusted outside the timer_list_next.

---
 kernel/time/timer_list.c |   41 ++++++++++++++++++++++++-----------------
 1 file changed, 24 insertions(+), 17 deletions(-)
kernel/time/timer_list.c +24 -17
@@ -265,10 +265,9 @@ static inline void timer_list_header(str
 static int timer_list_show(struct seq_file *m, void *v)
 {
 	struct timer_list_iter *iter = v;
-	u64 now = ktime_to_ns(ktime_get());
 
 	if (iter->cpu == -1 && !iter->second_pass)
-		timer_list_header(m, now);
+		timer_list_header(m, iter->now);
 	else if (!iter->second_pass)
 		print_cpu(m, iter->cpu, iter->now);
 #ifdef CONFIG_GENERIC_CLOCKEVENTS
@@ -298,33 +297,41 @@ void sysrq_timer_list_show(void)
 	return;
 }
 
-static void *timer_list_start(struct seq_file *file, loff_t *offset)
+static void *move_iter(struct timer_list_iter *iter, loff_t offset)
 {
-	struct timer_list_iter *iter = file->private;
-
-	if (!*offset) {
-		iter->cpu = -1;
-		iter->now = ktime_to_ns(ktime_get());
-	} else if (iter->cpu >= nr_cpu_ids) {
+	for (; offset; offset--) {
+		iter->cpu = cpumask_next(iter->cpu, cpu_online_mask);
+		if (iter->cpu >= nr_cpu_ids) {
 #ifdef CONFIG_GENERIC_CLOCKEVENTS
-		if (!iter->second_pass) {
-			iter->cpu = -1;
-			iter->second_pass = true;
-		} else
-			return NULL;
+			if (!iter->second_pass) {
+				iter->cpu = -1;
+				iter->second_pass = true;
+			} else
+				return NULL;
 #else
-		return NULL;
+			return NULL;
 #endif
+		}
 	}
 	return iter;
 }
 
+static void *timer_list_start(struct seq_file *file, loff_t *offset)
+{
+	struct timer_list_iter *iter = file->private;
+
+	if (!*offset)
+		iter->now = ktime_to_ns(ktime_get());
+	iter->cpu = -1;
+	iter->second_pass = false;
+	return move_iter(iter, *offset);
+}
+
 static void *timer_list_next(struct seq_file *file, void *v, loff_t *offset)
 {
 	struct timer_list_iter *iter = file->private;
-	iter->cpu = cpumask_next(iter->cpu, cpu_online_mask);
 	++*offset;
-	return timer_list_start(file, offset);
+	return move_iter(iter, 1);
 }
 
 static void timer_list_stop(struct seq_file *seq, void *v)
author maintainer
#12 lore raw

PATCH 12/36 IPC: bugfix for msgrcv with msgtyp < 0

In reply to Greg Kroah-Hartman

3.10-stable review patch. If anyone has any objections, please let me know.

------------------

From: Svenning Soerensen <[email protected]>

commit 368ae537e056acd3f751fa276f48423f06803922 upstream.

According to 'man msgrcv': "If msgtyp is less than 0, the first message of the lowest type that is less than or equal to the absolute value of msgtyp shall be received."

Bug: The kernel only returns a message if its type is 1; other messages with type < abs(msgtype) will never get returned.

Fix: After having traversed the list to find the first message with the lowest type, we need to actually return that message.

This regression was introduced by commit daaf74cf0867 ("ipc: refactor msg list search into separate function")

---
 ipc/msg.c |    5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)
ipc/msg.c +3 -2
@@ -795,7 +795,7 @@ static inline void free_copy(struct msg_
 
 static struct msg_msg *find_msg(struct msg_queue *msq, long *msgtyp, int mode)
 {
-	struct msg_msg *msg;
+	struct msg_msg *msg, *found = NULL;
 	long count = 0;
 
 	list_for_each_entry(msg, &msq->q_messages, m_list) {
@@ -804,6 +804,7 @@ static struct msg_msg *find_msg(struct m
 					       *msgtyp, mode)) {
 			if (mode == SEARCH_LESSEQUAL && msg->m_type != 1) {
 				*msgtyp = msg->m_type - 1;
+				found = msg;
 			} else if (mode == SEARCH_NUMBER) {
 				if (*msgtyp == count)
 					return msg;
@@ -813,7 +814,7 @@ static struct msg_msg *find_msg(struct m
 		}
 	}
 
-	return ERR_PTR(-EAGAIN);
+	return found ?: ERR_PTR(-EAGAIN);
 }
 
 
author maintainer
#13 lore raw

PATCH 13/36 drivers/base/memory.c: fix show_mem_removable() to handle missing sections

In reply to Greg Kroah-Hartman

3.10-stable review patch. If anyone has any objections, please let me know.

------------------

From: Russ Anderson <[email protected]>

commit 21ea9f5ace3a7317cc3ba1fbc749758021a83136 upstream.

"cat /sys/devices/system/memory/memory*/removable" crashed the system.

The problem is that show_mem_removable() is passing a bad pfn to is_mem_section_removable(), which causes

    if (!node_online(page_to_nid(page)))

to blow up. Why is it passing in a bad pfn?

The reason is that show_mem_removable() will loop sections_per_block times. sections_per_block is 16, but mem->section_count is 8, indicating holes in this memory block. Checking that the memory section is present before checking to see if the memory section is removable fixes the problem.

harp5-sys:~ # cat /sys/devices/system/memory/memory*/removable 0
1
1
1
1
1
1
1
1
1
1
1
1
1

   BUG: unable to handle kernel paging request at ffffea00c3200000
   IP: [<ffffffff81117ed1>] is_pageblock_removable_nolock+0x1/0x90
   PGD 83ffd4067 PUD 37bdfce067 PMD 0
   Oops: 0000 [#1] SMP
   Modules linked in: autofs4 binfmt_misc rdma_ucm rdma_cm iw_cm ib_addr ib_srp scsi_transport_srp scsi_tgt ib_ipoib ib_cm ib_uverbs ib_umad iw_cxgb3 cxgb3 mdio mlx4_en mlx4_ib ib_sa mlx4_core ib_mthca ib_mad ib_core fuse nls_iso8859_1 nls_cp437 vfat fat joydev loop hid_generic usbhid hid hwperf(O) numatools(O) dm_mod iTCO_wdt ipv6 iTCO_vendor_support igb i2c_i801 ioatdma i2c_algo_bit ehci_pci pcspkr lpc_ich i2c_core ehci_hcd ptp sg mfd_core dca rtc_cmos pps_core mperf button xhci_hcd sd_mod crc_t10dif usbcore usb_common scsi_dh_emc scsi_dh_hp_sw scsi_dh_alua scsi_dh_rdac scsi_dh gru(O) xvma(O) xfs crc32c libcrc32c thermal sata_nv processor piix mptsas mptscsih scsi_transport_sas mptbase megaraid_sas fan thermal_sys hwmon ext3 jbd ata_piix ahci libahci libata scsi_mod
   CPU: 4 PID: 5991 Comm: cat Tainted: G           O 3.11.0-rc5-rja-uv+ #10
   Hardware name: SGI UV2000/ROMLEY, BIOS SGI UV 2000/3000 series BIOS 01/15/2013
   task: ffff88081f034580 ti: ffff880820022000 task.ti: ffff880820022000
   RIP: 0010:[<ffffffff81117ed1>]  [<ffffffff81117ed1>] is_pageblock_removable_nolock+0x1/0x90
   RSP: 0018:ffff880820023df8  EFLAGS: 00010287
   RAX: 0000000000040000 RBX: ffffea00c3200000 RCX: 0000000000000004
   RDX: ffffea00c30b0000 RSI: 00000000001c0000 RDI: ffffea00c3200000
   RBP: ffff880820023e38 R08: 0000000000000000 R09: 0000000000000001
   R10: 0000000000000000 R11: 0000000000000001 R12: ffffea00c33c0000
   R13: 0000160000000000 R14: 6db6db6db6db6db7 R15: 0000000000000001
   FS:  00007ffff7fb2700(0000) GS:ffff88083fc80000(0000) knlGS:0000000000000000
   CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
   CR2: ffffea00c3200000 CR3: 000000081b954000 CR4: 00000000000407e0
   Call Trace:
     show_mem_removable+0x41/0x70
     dev_attr_show+0x2a/0x60
     sysfs_read_file+0xf7/0x1c0
     vfs_read+0xc8/0x130
     SyS_read+0x5d/0xa0
     system_call_fastpath+0x16/0x1b
---
 drivers/base/memory.c |    2 ++
 1 file changed, 2 insertions(+)
drivers/base/memory.c +2 -0
@@ -152,6 +152,8 @@ static ssize_t show_mem_removable(struct
 		container_of(dev, struct memory_block, dev);
 
 	for (i = 0; i < sections_per_block; i++) {
+		if (!present_section_nr(mem->start_section_nr + i))
+			continue;
 		pfn = section_nr_to_pfn(mem->start_section_nr + i);
 		ret &= is_mem_section_removable(pfn, PAGES_PER_SECTION);
 	}
author maintainer
#14 lore raw

PATCH 14/36 memcg: check that kmem_cache has memcg_params before accessing it

In reply to Greg Kroah-Hartman

3.10-stable review patch. If anyone has any objections, please let me know.

------------------

From: Andrey Vagin <[email protected]>

commit 6f6b8951897e487ea6f77b90ea01f70a9c363770 upstream.

If the system had a few memory groups and all of them were destroyed, memcg_limited_groups_array_size has non-zero value, but all new caches are created without memcg_params, because memcg_kmem_enabled() returns false.

We try to enumirate child caches in a few places and all of them are potentially dangerous.

For example my kernel is compiled with CONFIG_SLAB and it crashed when I tryed to mount a NFS share after a few experiments with kmemcg.

  BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
  IP: [<ffffffff8118166a>] do_tune_cpucache+0x8a/0xd0
  PGD b942a067 PUD b999f067 PMD 0
  Oops: 0000 [#1] SMP
  Modules linked in: fscache(+) ip6table_filter ip6_tables iptable_filter ip_tables i2c_piix4 pcspkr virtio_net virtio_balloon i2c_core floppy
  CPU: 0 PID: 357 Comm: modprobe Not tainted 3.11.0-rc7+ #59
  Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
  task: ffff8800b9f98240 ti: ffff8800ba32e000 task.ti: ffff8800ba32e000
  RIP: 0010:[<ffffffff8118166a>]  [<ffffffff8118166a>] do_tune_cpucache+0x8a/0xd0
  RSP: 0018:ffff8800ba32fb70  EFLAGS: 00010246
  RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000006
  RDX: 0000000000000000 RSI: ffff8800b9f98910 RDI: 0000000000000246
  RBP: ffff8800ba32fba0 R08: 0000000000000002 R09: 0000000000000004
  R10: 0000000000000001 R11: 0000000000000001 R12: 0000000000000010
  R13: 0000000000000008 R14: 00000000000000d0 R15: ffff8800375d0200
  FS:  00007f55f1378740(0000) GS:ffff8800bfa00000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
  CR2: 00007f24feba57a0 CR3: 0000000037b51000 CR4: 00000000000006f0
  Call Trace:
    enable_cpucache+0x49/0x100
    setup_cpu_cache+0x215/0x280
    __kmem_cache_create+0x2fa/0x450
    kmem_cache_create_memcg+0x214/0x350
    kmem_cache_create+0x2b/0x30
    fscache_init+0x19b/0x230 [fscache]
    do_one_initcall+0xfa/0x1b0
    load_module+0x1c41/0x26d0
    SyS_finit_module+0x86/0xb0
    system_call_fastpath+0x16/0x1b
Cc Pekka Enberg <[email protected]>
Cc Christoph Lameter <[email protected]>
Cc Glauber Costa <[email protected]>
Cc Joonsoo Kim <[email protected]>
Cc Michal Hocko <[email protected]>
Cc Johannes Weiner <[email protected]>
---
 mm/slab.h |    2 ++
 1 file changed, 2 insertions(+)
mm/slab.h +2 -0
@@ -162,6 +162,8 @@ static inline const char *cache_name(str
 
 static inline struct kmem_cache *cache_from_memcg(struct kmem_cache *s, int idx)
 {
+	if (!s->memcg_params)
+		return NULL;
 	return s->memcg_params->memcg_caches[idx];
 }
 
author maintainer
#15 lore raw

PATCH 15/36 workqueue: cond_resched() after processing each work item

In reply to Greg Kroah-Hartman

3.10-stable review patch. If anyone has any objections, please let me know.

------------------

From: Tejun Heo <[email protected]>

commit b22ce2785d97423846206cceec4efee0c4afd980 upstream.

If !PREEMPT, a kworker running work items back to back can hog CPU. This becomes dangerous when a self-requeueing work item which is waiting for something to happen races against stop_machine. Such self-requeueing work item would requeue itself indefinitely hogging the kworker and CPU it's running on while stop_machine would wait for that CPU to enter stop_machine while preventing anything else from happening on all other CPUs. The two would deadlock.

Jamie Liu reports that this deadlock scenario exists around scsi_requeue_run_queue() and libata port multiplier support, where one port may exclude command processing from other ports. With the right timing, scsi_requeue_run_queue() can end up requeueing itself trying to execute an IO which is asked to be retried while another device has an exclusive access, which in turn can't make forward progress due to stop_machine.

Fix it by invoking cond_resched() after executing each work item.

References: http://thread.gmane.org/gmane.linux.kernel/1552567

---
 kernel/workqueue.c |    9 +++++++++
 1 file changed, 9 insertions(+)
kernel/workqueue.c +9 -0
@@ -2188,6 +2188,15 @@ __acquires(&pool->lock)
 		dump_stack();
 	}
 
+	/*
+	 * The following prevents a kworker from hogging CPU on !PREEMPT
+	 * kernels, where a requeueing work item waiting for something to
+	 * happen could deadlock with stop_machine as such work item could
+	 * indefinitely requeue itself while all other CPUs are trapped in
+	 * stop_machine.
+	 */
+	cond_resched();
+
 	spin_lock_irq(&pool->lock);
 
 	/* clear cpu intensive status */
author maintainer
#16 lore raw

PATCH 16/36 drm/vmwgfx: Split GMR2_REMAP commands if they are to large

In reply to Greg Kroah-Hartman

3.10-stable review patch. If anyone has any objections, please let me know.

------------------

From: Jakob Bornecrantz <[email protected]>

commit 6e4dcff3adbf25acb87e74500a58e3c07bdec40f upstream.

This fixes the piglit test texturing/max-texture-size causing the VM to die due to a too large SVGA command.

---
 drivers/gpu/drm/vmwgfx/vmwgfx_gmr.c |   60 ++++++++++++++++++++++++------------
 1 file changed, 40 insertions(+), 20 deletions(-)
drivers/gpu/drm/vmwgfx/vmwgfx_gmr.c +40 -20
@@ -29,7 +29,9 @@
 #include <drm/drmP.h>
 #include <drm/ttm/ttm_bo_driver.h>
 
-#define VMW_PPN_SIZE sizeof(unsigned long)
+#define VMW_PPN_SIZE (sizeof(unsigned long))
+/* A future safe maximum remap size. */
+#define VMW_PPN_PER_REMAP ((31 * 1024) / VMW_PPN_SIZE)
 
 static int vmw_gmr2_bind(struct vmw_private *dev_priv,
 			 struct page *pages[],
@@ -38,43 +40,61 @@ static int vmw_gmr2_bind(struct vmw_priv
 {
 	SVGAFifoCmdDefineGMR2 define_cmd;
 	SVGAFifoCmdRemapGMR2 remap_cmd;
-	uint32_t define_size = sizeof(define_cmd) + 4;
-	uint32_t remap_size = VMW_PPN_SIZE * num_pages + sizeof(remap_cmd) + 4;
 	uint32_t *cmd;
 	uint32_t *cmd_orig;
+	uint32_t define_size = sizeof(define_cmd) + sizeof(*cmd);
+	uint32_t remap_num = num_pages / VMW_PPN_PER_REMAP + ((num_pages % VMW_PPN_PER_REMAP) > 0);
+	uint32_t remap_size = VMW_PPN_SIZE * num_pages + (sizeof(remap_cmd) + sizeof(*cmd)) * remap_num;
+	uint32_t remap_pos = 0;
+	uint32_t cmd_size = define_size + remap_size;
 	uint32_t i;
 
-	cmd_orig = cmd = vmw_fifo_reserve(dev_priv, define_size + remap_size);
+	cmd_orig = cmd = vmw_fifo_reserve(dev_priv, cmd_size);
 	if (unlikely(cmd == NULL))
 		return -ENOMEM;
 
 	define_cmd.gmrId = gmr_id;
 	define_cmd.numPages = num_pages;
 
+	*cmd++ = SVGA_CMD_DEFINE_GMR2;
+	memcpy(cmd, &define_cmd, sizeof(define_cmd));
+	cmd += sizeof(define_cmd) / sizeof(*cmd);
+
+	/*
+	 * Need to split the command if there are too many
+	 * pages that goes into the gmr.
+	 */
+
 	remap_cmd.gmrId = gmr_id;
 	remap_cmd.flags = (VMW_PPN_SIZE > sizeof(*cmd)) ?
 		SVGA_REMAP_GMR2_PPN64 : SVGA_REMAP_GMR2_PPN32;
-	remap_cmd.offsetPages = 0;
-	remap_cmd.numPages = num_pages;
 
-	*cmd++ = SVGA_CMD_DEFINE_GMR2;
-	memcpy(cmd, &define_cmd, sizeof(define_cmd));
-	cmd += sizeof(define_cmd) / sizeof(uint32);
+	while (num_pages > 0) {
+		unsigned long nr = min(num_pages, (unsigned long)VMW_PPN_PER_REMAP);
+
+		remap_cmd.offsetPages = remap_pos;
+		remap_cmd.numPages = nr;
 
-	*cmd++ = SVGA_CMD_REMAP_GMR2;
-	memcpy(cmd, &remap_cmd, sizeof(remap_cmd));
-	cmd += sizeof(remap_cmd) / sizeof(uint32);
-
-	for (i = 0; i < num_pages; ++i) {
-		if (VMW_PPN_SIZE <= 4)
-			*cmd = page_to_pfn(*pages++);
-		else
-			*((uint64_t *)cmd) = page_to_pfn(*pages++);
+		*cmd++ = SVGA_CMD_REMAP_GMR2;
+		memcpy(cmd, &remap_cmd, sizeof(remap_cmd));
+		cmd += sizeof(remap_cmd) / sizeof(*cmd);
+
+		for (i = 0; i < nr; ++i) {
+			if (VMW_PPN_SIZE <= 4)
+				*cmd = page_to_pfn(*pages++);
+			else
+				*((uint64_t *)cmd) = page_to_pfn(*pages++);
 
-		cmd += VMW_PPN_SIZE / sizeof(*cmd);
+			cmd += VMW_PPN_SIZE / sizeof(*cmd);
+		}
+
+		num_pages -= nr;
+		remap_pos += nr;
 	}
 
-	vmw_fifo_commit(dev_priv, define_size + remap_size);
+	BUG_ON(cmd != cmd_orig + cmd_size / sizeof(*cmd));
+
+	vmw_fifo_commit(dev_priv, cmd_size);
 
 	return 0;
 }
author maintainer
#17 lore raw

PATCH 17/36 drm/i915: ivb: fix edp voltage swing reg val

In reply to Greg Kroah-Hartman

3.10-stable review patch. If anyone has any objections, please let me know.

------------------

From: Imre Deak <[email protected]>

commit 77fa4cbd5fa389e28419bbe8ac491b5fdd54840d upstream.

Fix the typo introduced in

commit 1a2eb4604b85c5efb343da8a4dcf41288fcfca85

Author: Keith Packard <[email protected]>
Date:   Wed Nov 16 16:26:07 2011 -0800

drm/i915: Hook up Ivybridge eDP

This fixes eDP link-training failures and cases where all voltage swing /pre-emphasis levels were tried and failed during clock recovery and - as a fallback - we go on to do channel equalization with the last voltage swing/pre-emphasis level which will succeed. Both issues can lead to a blank screen.

v2:
- improve commit message

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=64880

---
 drivers/gpu/drm/i915/i915_reg.h |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/gpu/drm/i915/i915_reg.h +1 -1
@@ -4246,7 +4246,7 @@
 #define EDP_LINK_TRAIN_600MV_0DB_IVB		(0x30 <<22)
 #define EDP_LINK_TRAIN_600MV_3_5DB_IVB		(0x36 <<22)
 #define EDP_LINK_TRAIN_800MV_0DB_IVB		(0x38 <<22)
-#define EDP_LINK_TRAIN_800MV_3_5DB_IVB		(0x33 <<22)
+#define EDP_LINK_TRAIN_800MV_3_5DB_IVB		(0x3e <<22)
 
 /* legacy values */
 #define EDP_LINK_TRAIN_500MV_0DB_IVB		(0x00 <<22)
author maintainer
#18 lore raw

PATCH 18/36 SUNRPC: Fix memory corruption issue on 32-bit highmem systems

In reply to Greg Kroah-Hartman

3.10-stable review patch. If anyone has any objections, please let me know.

------------------

From: Trond Myklebust <[email protected]>

commit 347e2233b7667e336d9f671f1a52dfa3f0416e2c upstream.

Some architectures, such as ARM-32 do not return the same base address when you call kmap_atomic() twice on the same page.
This causes problems for the memmove() call in the XDR helper routine "_shift_data_right_pages()", since it defeats the detection of overlapping memory ranges, and has been seen to corrupt memory.

The fix is to distinguish between the case where we're doing an inter-page copy or not. In the former case of we know that the memory ranges cannot possibly overlap, so we can additionally micro-optimise by replacing memmove() with memcpy().

---
 net/sunrpc/xdr.c |    9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)
net/sunrpc/xdr.c +6 -3
@@ -207,10 +207,13 @@ _shift_data_right_pages(struct page **pa
 		pgfrom_base -= copy;
 
 		vto = kmap_atomic(*pgto);
-		vfrom = kmap_atomic(*pgfrom);
-		memmove(vto + pgto_base, vfrom + pgfrom_base, copy);
+		if (*pgto != *pgfrom) {
+			vfrom = kmap_atomic(*pgfrom);
+			memcpy(vto + pgto_base, vfrom + pgfrom_base, copy);
+			kunmap_atomic(vfrom);
+		} else
+			memmove(vto + pgto_base, vto + pgfrom_base, copy);
 		flush_dcache_page(*pgto);
-		kunmap_atomic(vfrom);
 		kunmap_atomic(vto);
 
 	} while ((len -= copy) != 0);
author maintainer
#19 lore raw

PATCH 19/36 x86/mm: Fix boot crash with DEBUG_PAGE_ALLOC=y and more than 512G RAM

In reply to Greg Kroah-Hartman

3.10-stable review patch. If anyone has any objections, please let me know.

------------------

From: Yinghai Lu <[email protected]>

commit 527bf129f9a780e11b251cf2467dc30118a57d16 upstream.

Dave Hansen reported that systems between 500G and 600G RAM crash early if DEBUG_PAGEALLOC is selected.

Quoted 10 lines
[    0.000000] init_memory_mapping: [mem 0x00000000-0x000fffff]
[    0.000000]  [mem 0x00000000-0x000fffff] page 4k
[    0.000000] BRK [0x02086000, 0x02086fff] PGTABLE
[    0.000000] BRK [0x02087000, 0x02087fff] PGTABLE
[    0.000000] BRK [0x02088000, 0x02088fff] PGTABLE
[    0.000000] init_memory_mapping: [mem 0xe80ee00000-0xe80effffff]
[    0.000000]  [mem 0xe80ee00000-0xe80effffff] page 4k
[    0.000000] BRK [0x02089000, 0x02089fff] PGTABLE
[    0.000000] BRK [0x0208a000, 0x0208afff] PGTABLE
[    0.000000] Kernel panic - not syncing: alloc_low_page: ran out of memory

It turns out that we missed increasing needed pages in BRK to mapping initial 2M and [0,1M) when we switched to use the #PF handler to set memory mappings:

Quoted 5 lines

commit 8170e6bed465b4b0c7687f93e9948aca4358a33b

Author: H. Peter Anvin <[email protected]>
Date:   Thu Jan 24 12:19:52 2013 -0800

x86, 64bit: Use a #PF handler to materialize early mappings on demand

Before that, we had the maping from [0,512M) in head_64.S, and we can spare two pages [0-1M). After that change, we can not reuse pages anymore.

When we have more than 512M ram, we need an extra page for pgd page with [512G, 1024g).

Increase pages in BRK for page table to solve the boot crash.

---
 arch/x86/mm/init.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
arch/x86/mm/init.c +2 -2
@@ -78,8 +78,8 @@ __ref void *alloc_low_pages(unsigned int
 	return __va(pfn << PAGE_SHIFT);
 }
 
-/* need 4 4k for initial PMD_SIZE, 4k for 0-ISA_END_ADDRESS */
-#define INIT_PGT_BUF_SIZE	(5 * PAGE_SIZE)
+/* need 3 4k for initial PMD_SIZE,  3 4k for 0-ISA_END_ADDRESS */
+#define INIT_PGT_BUF_SIZE	(6 * PAGE_SIZE)
 RESERVE_BRK(early_pgt_alloc, INIT_PGT_BUF_SIZE);
 void  __init early_alloc_pgt_buf(void)
 {
author maintainer
#20 lore raw

PATCH 20/36 ath9k_htc: Restore skb headroom when returning skb to mac80211

In reply to Greg Kroah-Hartman

3.10-stable review patch. If anyone has any objections, please let me know.

------------------

From: Helmut Schaa <[email protected]>

commit d2e9fc141e2aa21f4b35ee27072d84e9aa6e2ba0 upstream.

ath9k_htc adds padding between the 802.11 header and the payload during TX by moving the header. When handing the frame back to mac80211 for TX status handling the header is not moved back into its original position. This can result in a too small skb headroom when entering ath9k_htc again (due to a soft retransmission for example) causing an skb_under_panic oops.

Fix this by moving the 802.11 header back into its original position before returning the frame to mac80211 as other drivers like rt2x00 or ath5k do.

---
 drivers/net/wireless/ath/ath9k/htc_drv_txrx.c |   10 ++++++++++
 1 file changed, 10 insertions(+)
drivers/net/wireless/ath/ath9k/htc_drv_txrx.c +10 -0
@@ -448,6 +448,7 @@ static void ath9k_htc_tx_process(struct
 	struct ieee80211_conf *cur_conf = &priv->hw->conf;
 	bool txok;
 	int slot;
+	int hdrlen, padsize;
 
 	slot = strip_drv_header(priv, skb);
 	if (slot < 0) {
@@ -504,6 +505,15 @@ send_mac80211:
 
 	ath9k_htc_tx_clear_slot(priv, slot);
 
+	/* Remove padding before handing frame back to mac80211 */
+	hdrlen = ieee80211_get_hdrlen_from_skb(skb);
+
+	padsize = hdrlen & 3;
+	if (padsize && skb->len > hdrlen + padsize) {
+		memmove(skb->data + padsize, skb->data, hdrlen);
+		skb_pull(skb, padsize);
+	}
+
 	/* Send status to mac80211 */
 	ieee80211_tx_status(priv->hw, skb);
 }
author maintainer
#21 lore raw

PATCH 21/36 ath9k: Enable PLL fix only for AR9340/AR9330

In reply to Greg Kroah-Hartman

3.10-stable review patch. If anyone has any objections, please let me know.

------------------

From: Sujith Manoharan <[email protected]>

commit 19c361608ce3e73f352e323262f7e0a8264be3af upstream.

The PLL hang workaround is required only for AR9330 and AR9340. This issue was first observed on an AP121 and the WAR is enabled for AR9340 also (DB120 etc.), since it uses a PLL design identical to AR9330. This is not required for AR9485 and AR9550.

Various bugs have been reported regarding this:

https://bugzilla.redhat.com/show_bug.cgi?id=997217
https://bugzilla.redhat.com/show_bug.cgi?id=994648

---
 drivers/net/wireless/ath/ath9k/main.c |    3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)
drivers/net/wireless/ath/ath9k/main.c +1 -2
@@ -173,8 +173,7 @@ static void ath_restart_work(struct ath_
 {
 	ieee80211_queue_delayed_work(sc->hw, &sc->tx_complete_work, 0);
 
-	if (AR_SREV_9340(sc->sc_ah) || AR_SREV_9485(sc->sc_ah) ||
-	    AR_SREV_9550(sc->sc_ah))
+	if (AR_SREV_9340(sc->sc_ah) || AR_SREV_9330(sc->sc_ah))
 		ieee80211_queue_delayed_work(sc->hw, &sc->hw_pll_work,
 				     msecs_to_jiffies(ATH_PLL_WORK_INTERVAL));
 
author maintainer
#22 lore raw

PATCH 22/36 mac80211: add missing channel context release

In reply to Greg Kroah-Hartman

3.10-stable review patch. If anyone has any objections, please let me know.

------------------

From: Johannes Berg <[email protected]>

commit 2a3ba63c235fdcd37f6451bdf4a0c7865a3930cf upstream.

IBSS needs to release the channel context when leaving but I evidently missed that. Fix it.

---
 net/mac80211/ibss.c |    1 +
 1 file changed, 1 insertion(+)
net/mac80211/ibss.c +1 -0
@@ -1166,6 +1166,7 @@ int ieee80211_ibss_leave(struct ieee8021
 	clear_bit(SDATA_STATE_OFFCHANNEL_BEACON_STOPPED, &sdata->state);
 	ieee80211_bss_info_change_notify(sdata, BSS_CHANGED_BEACON_ENABLED |
 						BSS_CHANGED_IBSS);
+	ieee80211_vif_release_channel(sdata);
 	synchronize_rcu();
 	kfree(presp);
 
author maintainer
#23 lore raw

PATCH 23/36 mac80211: add a flag to indicate CCK support for HT clients

In reply to Greg Kroah-Hartman

3.10-stable review patch. If anyone has any objections, please let me know.

------------------

From: Felix Fietkau <[email protected]>

commit 2dfca312a91631311c1cf7c090246cc8103de038 upstream.

brcm80211 cannot handle sending frames with CCK rates as part of an A-MPDU session. Other drivers may have issues too. Set the flag in all drivers that have been tested with CCK rates.

This fixes a reported brcmsmac regression introduced in commit ef47a5e4f1aaf1d0e2e6875e34b2c9595897bef6 "mac80211/minstrel_ht: fix cck rate sampling"

---
 drivers/net/wireless/ath/ath9k/init.c    |    3 ++-
 drivers/net/wireless/ath/carl9170/main.c |    3 ++-
 drivers/net/wireless/rt2x00/rt2800lib.c  |    3 ++-
 include/net/mac80211.h                   |    1 +
 net/mac80211/rc80211_minstrel_ht.c       |    3 +++
 5 files changed, 10 insertions(+), 3 deletions(-)
drivers/net/wireless/ath/ath9k/init.c +2 -1
@@ -767,7 +767,8 @@ void ath9k_set_hw_capab(struct ath_softc
 		IEEE80211_HW_PS_NULLFUNC_STACK |
 		IEEE80211_HW_SPECTRUM_MGMT |
 		IEEE80211_HW_REPORTS_TX_ACK_STATUS |
-		IEEE80211_HW_SUPPORTS_RC_TABLE;
+		IEEE80211_HW_SUPPORTS_RC_TABLE |
+		IEEE80211_HW_SUPPORTS_HT_CCK_RATES;
 
 	if (sc->sc_ah->caps.hw_caps & ATH9K_HW_CAP_HT)
 		 hw->flags |= IEEE80211_HW_AMPDU_AGGREGATION;
drivers/net/wireless/ath/carl9170/main.c +2 -1
@@ -1857,7 +1857,8 @@ void *carl9170_alloc(size_t priv_size)
 		     IEEE80211_HW_SUPPORTS_PS |
 		     IEEE80211_HW_PS_NULLFUNC_STACK |
 		     IEEE80211_HW_NEED_DTIM_BEFORE_ASSOC |
-		     IEEE80211_HW_SIGNAL_DBM;
+		     IEEE80211_HW_SIGNAL_DBM |
+		     IEEE80211_HW_SUPPORTS_HT_CCK_RATES;
 
 	if (!modparam_noht) {
 		/*
drivers/net/wireless/rt2x00/rt2800lib.c +2 -1
@@ -5912,7 +5912,8 @@ static int rt2800_probe_hw_mode(struct r
 	    IEEE80211_HW_SUPPORTS_PS |
 	    IEEE80211_HW_PS_NULLFUNC_STACK |
 	    IEEE80211_HW_AMPDU_AGGREGATION |
-	    IEEE80211_HW_REPORTS_TX_ACK_STATUS;
+	    IEEE80211_HW_REPORTS_TX_ACK_STATUS |
+	    IEEE80211_HW_SUPPORTS_HT_CCK_RATES;
 
 	/*
 	 * Don't set IEEE80211_HW_HOST_BROADCAST_PS_BUFFERING for USB devices
include/net/mac80211.h +1 -0
@@ -1484,6 +1484,7 @@ enum ieee80211_hw_flags {
 	IEEE80211_HW_SUPPORTS_RC_TABLE			= 1<<24,
 	IEEE80211_HW_P2P_DEV_ADDR_FOR_INTF		= 1<<25,
 	IEEE80211_HW_TIMING_BEACON_ONLY			= 1<<26,
+	IEEE80211_HW_SUPPORTS_HT_CCK_RATES		= 1<<27,
 };
 
 /**
net/mac80211/rc80211_minstrel_ht.c +3 -0
@@ -828,6 +828,9 @@ minstrel_ht_update_cck(struct minstrel_p
 	if (sband->band != IEEE80211_BAND_2GHZ)
 		return;
 
+	if (!(mp->hw->flags & IEEE80211_HW_SUPPORTS_HT_CCK_RATES))
+		return;
+
 	mi->cck_supported = 0;
 	mi->cck_supported_short = 0;
 	for (i = 0; i < 4; i++) {
author maintainer
#24 lore raw

PATCH 24/36 iwl4965: fix rfkill set state regression

In reply to Greg Kroah-Hartman

3.10-stable review patch. If anyone has any objections, please let me know.

------------------

From: Stanislaw Gruszka <[email protected]>

commit b2fcc0aee58a3435566dd6d8501a0b355552f28b upstream.

My current 3.11 fix:

commit 788f7a56fce1bcb2067b62b851a086fca48a0056

Author: Stanislaw Gruszka <[email protected]>
Date:   Thu Aug 1 12:07:55 2013 +0200

iwl4965: reset firmware after rfkill off

broke rfkill notification to user-space . I missed that bug, because I compiled without CONFIG_RFKILL, sorry about that.

---
 drivers/net/wireless/iwlegacy/4965-mac.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/wireless/iwlegacy/4965-mac.c +1 -1
@@ -4446,9 +4446,9 @@ il4965_irq_tasklet(struct il_priv *il)
 			set_bit(S_RFKILL, &il->status);
 		} else {
 			clear_bit(S_RFKILL, &il->status);
-			wiphy_rfkill_set_hw_state(il->hw->wiphy, hw_rf_kill);
 			il_force_reset(il, true);
 		}
+		wiphy_rfkill_set_hw_state(il->hw->wiphy, hw_rf_kill);
 
 		handled |= CSR_INT_BIT_RF_KILL;
 	}
author maintainer
#25 lore raw

PATCH 25/36 target: Fix trailing ASCII space usage in INQUIRY vendor+model

In reply to Greg Kroah-Hartman

3.10-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.

---
 drivers/target/target_core_spc.c |    9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)
drivers/target/target_core_spc.c +6 -3
@@ -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;
author maintainer
#26 lore raw

PATCH 26/36 iscsi-target: Fix ImmediateData=Yes failure regression in >= v3.10

In reply to Greg Kroah-Hartman

3.10-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

---
 drivers/target/iscsi/iscsi_target.c |    9 ++-------
 1 file changed, 2 insertions(+), 7 deletions(-)
drivers/target/iscsi/iscsi_target.c +2 -7
@@ -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,
author maintainer
#27 lore raw

PATCH 27/36 iscsi-target: Fix iscsit_transport reference leak during NP thread reset

In reply to Greg Kroah-Hartman

3.10-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.

---
 drivers/target/iscsi/iscsi_target_login.c |    9 ++++-----
 1 file changed, 4 insertions(+), 5 deletions(-)
drivers/target/iscsi/iscsi_target_login.c +4 -5
@@ -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;
 		}
author maintainer
#28 lore raw

PATCH 28/36 iscsi-target: Fix potential NULL pointer in solicited NOPOUT reject

In reply to Greg Kroah-Hartman

3.10-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

---
 drivers/target/iscsi/iscsi_target.c |    8 ++++++++
 1 file changed, 8 insertions(+)
drivers/target/iscsi/iscsi_target.c +8 -0
@@ -1536,6 +1536,10 @@ int iscsit_handle_nop_out(struct iscsi_c
 	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);
 	}
@@ -1545,6 +1549,10 @@ int iscsit_handle_nop_out(struct iscsi_c
 			" 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);
 	}
author maintainer
#29 lore raw

PATCH 29/36 mei: me: fix hardware reset flow

In reply to Greg Kroah-Hartman

3.10-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

---
 drivers/misc/mei/hw-me.c |    8 +++-----
 1 file changed, 3 insertions(+), 5 deletions(-)
drivers/misc/mei/hw-me.c +3 -5
@@ -176,16 +176,14 @@ static void mei_me_hw_reset(struct mei_d
 	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);
author maintainer
#30 lore raw

PATCH 30/36 usb: acm gadget: Null termintate strings table

In reply to Greg Kroah-Hartman

3.10-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.

---
 drivers/usb/gadget/f_acm.c |    1 +
 1 file changed, 1 insertion(+)
drivers/usb/gadget/f_acm.c +1 -0
@@ -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 = {
author maintainer
#31 lore raw

PATCH 31/36 hwmon: (k10temp) Add support for Fam16h (Kabini)

In reply to Greg Kroah-Hartman

3.10-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.

---
 Documentation/hwmon/k10temp |    1 +
 drivers/hwmon/Kconfig       |    4 ++--
 drivers/hwmon/k10temp.c     |    3 ++-
 3 files changed, 5 insertions(+), 3 deletions(-)
Documentation/hwmon/k10temp +1 -0
@@ -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
drivers/hwmon/Kconfig +2 -2
@@ -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.
drivers/hwmon/k10temp.c +2 -1
@@ -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);
author maintainer
#32 lore raw

PATCH 32/36 ACPI / EC: Add ASUSTEK L4R to quirk list in order to validate ECDT

In reply to Greg Kroah-Hartman

3.10-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

---
 drivers/acpi/ec.c |    4 ++++
 1 file changed, 4 insertions(+)
drivers/acpi/ec.c +4 -0
@@ -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},
 	{},
 };
 
author maintainer
#33 lore raw

PATCH 33/36 drivers/misc/hpilo: Correct panic when an AUX iLO is detected

In reply to Greg Kroah-Hartman

3.10-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]
---
 drivers/misc/hpilo.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/misc/hpilo.c +2 -2
@@ -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]>");
author maintainer
#34 lore raw

PATCH 34/36 xen/arm: missing put_cpu in xen_percpu_init

In reply to Greg Kroah-Hartman

3.10-stable review patch. If anyone has any objections, please let me know.

------------------

From: Julien Grall <[email protected]>

commit 0d7febe58413884f6428143221971618fbf3a47d upstream.

When CONFIG_PREEMPT is enabled, Linux will not be able to boot and warn:

[    4.127825] ------------[ cut here ]------------
[    4.133376] WARNING: at init/main.c:699 do_one_initcall+0x150/0x158()
[    4.140738] initcall xen_init_events+0x0/0x10c returned with preemption imbalance

This is because xen_percpu_init uses get_cpu but doesn't have the corresponding put_cpu.

---
 arch/arm/xen/enlighten.c |    1 +
 1 file changed, 1 insertion(+)
arch/arm/xen/enlighten.c +1 -0
@@ -170,6 +170,7 @@ static void __init xen_percpu_init(void
 	per_cpu(xen_vcpu, cpu) = vcpup;
 
 	enable_percpu_irq(xen_events_irq, 0);
+	put_cpu();
 }
 
 static void xen_restart(char str, const char *cmd)
author maintainer
#35 lore raw

PATCH 35/36 imx-drm: imx-drm-core: Export imx_drm_encoder_get_mux_id

In reply to Greg Kroah-Hartman

3.10-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.

---
 drivers/staging/imx-drm/imx-drm-core.c |    1 +
 1 file changed, 1 insertion(+)
drivers/staging/imx-drm/imx-drm-core.c +1 -0
@@ -681,6 +681,7 @@ found:
 
 	return i;
 }
+EXPORT_SYMBOL_GPL(imx_drm_encoder_get_mux_id);
 
 /*
  * imx_drm_remove_encoder - remove an encoder
author maintainer
#36 lore raw

PATCH 36/36 regmap: rbtree: Fix overlapping rbnodes.

In reply to Greg Kroah-Hartman

3.10-stable review patch. If anyone has any objections, please let me know.

------------------

From: David Jander <[email protected]>

commit 4e67fb5f5e336250db944921e3c68057d6203034 upstream.

Avoid overlapping register regions by making the initial blklen of a new node 1. If a register write occurs to a yet uncached register, that is lower than but near an existing node's base_reg, a new node is created and it's blklen is set to an arbitrary value (sizeof(*rbnode)). That may cause this node to overlap with another node. Those nodes should be merged, but this merge doesn't happen yet, so this patch at least makes the initial blklen small enough to avoid hitting the wrong node, which may otherwise lead to severe breakage.

---
 drivers/base/regmap/regcache-rbtree.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/base/regmap/regcache-rbtree.c +1 -1
@@ -362,7 +362,7 @@ static int regcache_rbtree_write(struct
 		rbnode = kzalloc(sizeof *rbnode, GFP_KERNEL);
 		if (!rbnode)
 			return -ENOMEM;
-		rbnode->blklen = sizeof(*rbnode);
+		rbnode->blklen = 1;
 		rbnode->base_reg = reg;
 		rbnode->block = kmalloc(rbnode->blklen * map->cache_word_size,
 					GFP_KERNEL);
maintainer
#37 lore raw
In reply to Greg Kroah-Hartman
Quoted 5 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 3.10.11 release. There are 36 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.

Quoted 7 lines

Responses should be made by Sat Sep 7 20:26:25 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.10.11-rc1.gz

and the diffstat can be found below.

buildbot says:

        total: 100 pass: 100 skipped: 0 fail: 0

Just like the previous release, this is a perfect result. Time to add some failing builds to raise the challenge ?

qemu test runs for arm, microblaze, mips, mips64, ppc, x86, and x86_64 are fine.

Details are available at http://server.roeck-us.net:8010/builders.

Guenter

author maintainer
#38 lore raw
Quoted 9 lines · Guenter Roeck
Quoted 8 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 3.10.11 release. There are 36 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 7 20:26:25 UTC 2013. Anything received after that time might be too late.

Quoted 8 lines
Quoted 4 lines

The whole patch series can be found in one patch at:

	kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.10.11-rc1.gz

and the diffstat can be found below.

buildbot says:

        total: 100 pass: 100 skipped: 0 fail: 0

Just like the previous release, this is a perfect result. Time to add some failing builds to raise the challenge ?

Heh, no, I like it as-is :)

Quoted 1 line

qemu test runs for arm, microblaze, mips, mips64, ppc, x86, and x86_64 are fine.

Thanks for testing and letting me know.

greg k-h

#39 lore raw
In reply to Greg Kroah-Hartman
Quoted 8 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 3.10.11 release. There are 36 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 7 20:26:25 UTC 2013. Anything received after that time might be too late.

Quoted 8 lines

The whole patch series can be found in one patch at:

	kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.10.11-rc1.gz

and the diffstat can be found below.

thanks,

greg k-h

3.10.11-rc1 applied cleanly to 3.10.10

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.

Compile tested on Samsung Chromebook Exynos5 (ARMv7):
Note: Hoping to run boot tests on this new test system, but I was able to compile the 3.10.11-rc1 on this system running Ubuntu 13.04 so far.

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

Signature · 4 lines
Shuah Khan
Senior Linux Kernel Developer - Open Source Group
Samsung Research America(Silicon Valley)
[email protected] | (970) 672-0658
author maintainer
#40 lore raw
Quoted 20 lines · Shuah Khan
Quoted 8 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 3.10.11 release. There are 36 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 7 20:26:25 UTC 2013. Anything received after that time might be too late.

Quoted 8 lines

The whole patch series can be found in one patch at:

	kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.10.11-rc1.gz

and the diffstat can be found below.

thanks,

greg k-h

3.10.11-rc1 applied cleanly to 3.10.10

Quoted 8 lines

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.

Thanks for testing and letting me know.

Quoted 4 lines

Compile tested on Samsung Chromebook Exynos5 (ARMv7):
Note: Hoping to run boot tests on this new test system, but I was able to compile the 3.10.11-rc1 on this system running Ubuntu 13.04 so far.

"able", or "unable"? What's the problem you are getting?

thanks,

greg k-h

#41 lore raw
Quoted 30 lines · Greg Kroah-Hartman
Quoted 20 lines · Shuah Khan
Quoted 8 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 3.10.11 release. There are 36 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 7 20:26:25 UTC 2013. Anything received after that time might be too late.

Quoted 8 lines

The whole patch series can be found in one patch at:

	kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.10.11-rc1.gz

and the diffstat can be found below.

thanks,

greg k-h

3.10.11-rc1 applied cleanly to 3.10.10

Quoted 8 lines

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.

Quoted 9 lines

Thanks for testing and letting me know.

Quoted 4 lines

Compile tested on Samsung Chromebook Exynos5 (ARMv7):
Note: Hoping to run boot tests on this new test system, but I was able to compile the 3.10.11-rc1 on this system running Ubuntu 13.04 so far.

"able", or "unable"? What's the problem you are getting?

Compiled just fine. No issues with compile and installed fine. I am figuring out the boot-loader config on this system to be able to boot the new image. Will get there soon. :)

-- Shuah

Signature · 4 lines
Shuah Khan
Senior Linux Kernel Developer - Open Source Group
Samsung Research America(Silicon Valley)
[email protected] | (970) 672-0658
#42 lore raw
In reply to Greg Kroah-Hartman
Quoted 11 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 3.10.11 release. There are 36 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 7 20:26:25 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.10.11-rc1.gz

and the diffstat can be found below.

FYI; I've started tracking the 3.10+ queues on my builder/booter for arm-soc platforms.

I don't plan on posting the logs but will keep an eye on them and report (new) failures that aren't seen on the baseline. I poll for new patches a few times an hour.

-Olof

author maintainer
#43 lore raw
Quoted 14 lines · Olof Johansson
Quoted 11 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 3.10.11 release. There are 36 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 7 20:26:25 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.10.11-rc1.gz

and the diffstat can be found below.

Quoted 6 lines

FYI; I've started tracking the 3.10+ queues on my builder/booter for arm-soc platforms.

I don't plan on posting the logs but will keep an eye on them and report (new) failures that aren't seen on the baseline. I poll for new patches a few times an hour.

That would be great to know, thanks for doing this.

greg k-h