[ 00/34] 3.4.59-stable review

[ 00/34] 3.4.59-stable review

[Greg Kroah-Hartman]

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

Note, there are a number of "build fixes" in this round, in the quest to
get all arches building properly to be able to track future regressions
easier.  Many thanks to Guenter Roeck and Geert Uytterhoeven for their
work in doing this.

Responses should be made by Tue Aug 20 20:32:48 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.4.59-rc1.gz
and the diffstat can be found below.

thanks,

greg k-h

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

Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Linux 3.4.59-rc1

Jan Kara <jack@suse.cz>
    jbd2: Fix use after free after error in jbd2_journal_dirty_metadata()

Geert Uytterhoeven <geert@linux-m68k.org>
    m68k/atari: ARAnyM - Fix NatFeat module support

Andreas Schwab <schwab@linux-m68k.org>
    m68k: Truncate base in do_div()

Will Deacon <will.deacon@arm.com>
    ARM: 7809/1: perf: fix event validation for software group leaders

Geert Uytterhoeven <geert@linux-m68k.org>
    xtensa: replace xtensa-specific _f{data,text} by _s{data,text}

Max Filippov <jcmvbkbc@gmail.com>
    xtensa: fix linker script transformation for .text.unlikely

Johan Hovold <jhovold@gmail.com>
    USB: mos7720: fix broken control requests

Oliver Neukum <oneukum@suse.de>
    usb: add two quirky touchscreen

Johannes Berg <johannes.berg@intel.com>
    genetlink: fix family dump race

Stephane Grosjean <s.grosjean@peak-system.com>
    can: pcan_usb: fix wrong memcpy() bytes length

Stanislaw Gruszka <sgruszka@redhat.com>
    iwl4965: reset firmware after rfkill off

Stanislaw Gruszka <sgruszka@redhat.com>
    iwl4965: set power mode early

Nicolas Dichtel <nicolas.dichtel@6wind.com>
    af_key: initialize satype in key_notify_policy_flush()

Ralf Baechle <ralf@linux-mips.org>
    MIPS: Rewrite pfn_valid to work in modules, too.

David S. Miller <davem@davemloft.net>
    sparc32: Add ucmpdi2.o to obj-y instead of lib-y.

Sam Ravnborg <sam@ravnborg.org>
    sparc32: add ucmpdi2

NeilBrown <neilb@suse.de>
    md/raid1,raid10: use freeze_array in place of raise_barrier in various places.

Will Deacon <will.deacon@arm.com>
    alpha: makefile: don't enforce small data model for kernel builds

Benjamin Herrenschmidt <benh@kernel.crashing.org>
    powerpc/numa: Avoid stupid uninitialized warning from gcc

Thomas Gleixner <tglx@linutronix.de>
    frv: Use core allocator for task_struct

Thomas Gleixner <tglx@linutronix.de>
    frv: Use correct size for task_struct allocation

Zhang Yi <wetpzy@gmail.com>
    futex: Take hugepages into account when generating futex_key

Jesper Nilsson <jesper.nilsson@axis.com>
    CRIS: Add _sdata to vmlinux.lds.S

Paul Gortmaker <paul.gortmaker@windriver.com>
    cris: Remove old legacy "-traditional" flag from arch-v10/lib/Makefile

Jiri Slaby <jslaby@suse.cz>
    cris: posix_types.h, include asm-generic/posix_types.h

Linus Torvalds <torvalds@linux-foundation.org>
    vm: add no-mmu vm_iomap_memory() stub

Jiri Slaby <jslaby@suse.cz>
    HID: microsoft: do not use compound literal - fix build

Paul Bolle <pebolle@tiscali.nl>
    sound: Fix make allmodconfig on MIPS correctly

Takashi Iwai <tiwai@suse.de>
    sound: Fix make allmodconfig on MIPS

Michal Simek <michal.simek@xilinx.com>
    microblaze: Update microblaze defconfigs

Markos Chandras <markos.chandras@imgtec.com>
    MIPS: Expose missing pci_io{map,unmap} declarations

Daniel Vetter <daniel.vetter@ffwll.ch>
    drm/i915/lvds: ditch ->prepare special case

yonghua zheng <younghua.zheng@gmail.com>
    fs/proc/task_mmu.c: fix buffer overflow in add_page_map()

Stephen Boyd <sboyd@codeaurora.org>
    perf/arm: Fix armpmu_map_hw_event()


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

Diffstat:

 Makefile                                 |  4 +-
 arch/alpha/Makefile                      |  2 +-
 arch/arm/kernel/perf_event.c             | 10 ++++-
 arch/cris/arch-v10/lib/Makefile          |  3 --
 arch/cris/include/asm/posix_types.h      |  2 +
 arch/cris/kernel/vmlinux.lds.S           |  1 +
 arch/frv/include/asm/thread_info.h       |  2 -
 arch/frv/kernel/process.c                | 15 -------
 arch/m68k/emu/natfeat.c                  | 23 +++++++++--
 arch/m68k/include/asm/div64.h            |  9 ++--
 arch/microblaze/configs/mmu_defconfig    | 49 +++++++++++++++-------
 arch/microblaze/configs/nommu_defconfig  | 71 +++++++++++++++++++-------------
 arch/mips/Kconfig                        |  2 +-
 arch/mips/include/asm/io.h               |  5 +++
 arch/mips/include/asm/page.h             | 17 ++++----
 arch/powerpc/mm/numa.c                   |  2 +-
 arch/sparc/lib/Makefile                  |  2 +-
 arch/sparc/lib/ucmpdi2.c                 | 19 +++++++++
 arch/xtensa/kernel/Makefile              |  1 +
 arch/xtensa/kernel/vmlinux.lds.S         |  3 +-
 arch/xtensa/mm/init.c                    |  6 +--
 drivers/gpu/drm/i915/intel_lvds.c        |  8 +---
 drivers/hid/hid-microsoft.c              |  6 +--
 drivers/md/raid1.c                       | 22 +++++-----
 drivers/md/raid10.c                      | 14 +++----
 drivers/net/can/usb/peak_usb/pcan_usb.c  |  2 +-
 drivers/net/wireless/iwlegacy/4965-mac.c | 16 +++----
 drivers/net/wireless/iwlegacy/common.c   |  1 +
 drivers/usb/core/quirks.c                |  6 +++
 drivers/usb/serial/mos7720.c             | 21 ++++++----
 fs/ext4/ext4_jbd2.c                      |  8 ++--
 fs/proc/task_mmu.c                       |  8 ++--
 include/linux/hugetlb.h                  | 16 +++++++
 kernel/futex.c                           |  3 +-
 mm/hugetlb.c                             | 17 ++++++++
 mm/nommu.c                               | 10 +++++
 net/key/af_key.c                         |  1 +
 net/netlink/genetlink.c                  |  7 ++++
 sound/oss/Kconfig                        |  1 +
 39 files changed, 269 insertions(+), 146 deletions(-)

[ 01/34] perf/arm: Fix armpmu_map_hw_event()

[Greg Kroah-Hartman]

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

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

From: Stephen Boyd <sboyd@codeaurora.org>

commit b88a2595b6d8aedbd275c07dfa784657b4f757eb upstream.

Fix constraint check in armpmu_map_hw_event().

Reported-and-tested-by: Vince Weaver <vincent.weaver@maine.edu>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 arch/arm/kernel/perf_event.c |    7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

--- a/arch/arm/kernel/perf_event.c
+++ b/arch/arm/kernel/perf_event.c
@@ -109,7 +109,12 @@ armpmu_map_cache_event(const unsigned (*
 static int
 armpmu_map_event(const unsigned (*event_map)[PERF_COUNT_HW_MAX], u64 config)
 {
-	int mapping = (*event_map)[config];
+	int mapping;
+
+	if (config >= PERF_COUNT_HW_MAX)
+		return -ENOENT;
+
+	mapping = (*event_map)[config];
 	return mapping == HW_OP_UNSUPPORTED ? -ENOENT : mapping;
 }
 

[ 02/34] fs/proc/task_mmu.c: fix buffer overflow in add_page_map()

[Greg Kroah-Hartman]

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

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

From: yonghua zheng <younghua.zheng@gmail.com>

commit 8c8296223f3abb142be8fc31711b18a704c0e7d8 upstream.

Recently we met quite a lot of random kernel panic issues after enabling
CONFIG_PROC_PAGE_MONITOR.  After debuggind we found this has something
to do with following bug in pagemap:

In struct pagemapread:

  struct pagemapread {
      int pos, len;
      pagemap_entry_t *buffer;
      bool v2;
  };

pos is number of PM_ENTRY_BYTES in buffer, but len is the size of
buffer, it is a mistake to compare pos and len in add_page_map() for
checking buffer is full or not, and this can lead to buffer overflow and
random kernel panic issue.

Correct len to be total number of PM_ENTRY_BYTES in buffer.

[akpm@linux-foundation.org: document pagemapread.pos and .len units, fix PM_ENTRY_BYTES definition]
Signed-off-by: Yonghua Zheng <younghua.zheng@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 fs/proc/task_mmu.c |    8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

--- a/fs/proc/task_mmu.c
+++ b/fs/proc/task_mmu.c
@@ -679,14 +679,14 @@ typedef struct {
 } pagemap_entry_t;
 
 struct pagemapread {
-	int pos, len;
+	int pos, len;		/* units: PM_ENTRY_BYTES, not bytes */
 	pagemap_entry_t *buffer;
 };
 
 #define PAGEMAP_WALK_SIZE	(PMD_SIZE)
 #define PAGEMAP_WALK_MASK	(PMD_MASK)
 
-#define PM_ENTRY_BYTES      sizeof(u64)
+#define PM_ENTRY_BYTES      sizeof(pagemap_entry_t)
 #define PM_STATUS_BITS      3
 #define PM_STATUS_OFFSET    (64 - PM_STATUS_BITS)
 #define PM_STATUS_MASK      (((1LL << PM_STATUS_BITS) - 1) << PM_STATUS_OFFSET)
@@ -913,8 +913,8 @@ static ssize_t pagemap_read(struct file
 	if (!count)
 		goto out_task;
 
-	pm.len = PM_ENTRY_BYTES * (PAGEMAP_WALK_SIZE >> PAGE_SHIFT);
-	pm.buffer = kmalloc(pm.len, GFP_TEMPORARY);
+	pm.len = (PAGEMAP_WALK_SIZE >> PAGE_SHIFT);
+	pm.buffer = kmalloc(pm.len * PM_ENTRY_BYTES, GFP_TEMPORARY);
 	ret = -ENOMEM;
 	if (!pm.buffer)
 		goto out_task;

[ 03/34] drm/i915/lvds: ditch ->prepare special case

[Greg Kroah-Hartman]

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

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

From: Daniel Vetter <daniel.vetter@ffwll.ch>

commit 520c41cf2fa029d1e8b923ac2026f96664f17c4b upstream.

LVDS is the first output where dpms on/off and prepare/commit don't
perfectly match. Now the idea behind this special case seems to be
that for simple resolution changes on the LVDS we don't need to stop
the pipe, because (at least on newer chips) we can adjust the panel
fitter on the fly.

There are a few problems with the current code though:
- We still stop and restart the pipe unconditionally, because the crtc
  helper code isn't flexible enough.
- We show some ugly flickering, especially when changing crtcs (this
  the crtc helper would actually take into account, but we don't
  implement the encoder->get_crtc callback required to make this work
  properly).

So it doesn't even work as advertised. I agree that it would be nice
to do resolution changes on LVDS (and also eDP) whithout blacking the
screen where the panel fitter allows to do that. But imo we should
implement this as a special case a few layers up in the mode set code,
akin to how we already detect simple framebuffer changes (and only
update the required registers with ->mode_set_base).

Until this is all in place, make our lives easier and just rip it out.

Also note that this seems to fix actual bugs with enabling the lvds
output, see:

http://lists.freedesktop.org/archives/intel-gfx/2012-July/018614.html

Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Takashi Iwai <tiwai@suse.de>
Cc: Giacomo Comes <comes@naic.edu>
Tested-by: Takashi Iwai <tiwai@suse.de>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Haitao Zhang <haitao.zhang@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/gpu/drm/i915/intel_lvds.c |    8 +-------
 1 file changed, 1 insertion(+), 7 deletions(-)

--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -408,13 +408,7 @@ static void intel_lvds_prepare(struct dr
 {
 	struct intel_lvds *intel_lvds = to_intel_lvds(encoder);
 
-	/*
-	 * Prior to Ironlake, we must disable the pipe if we want to adjust
-	 * the panel fitter. However at all other times we can just reset
-	 * the registers regardless.
-	 */
-	if (!HAS_PCH_SPLIT(encoder->dev) && intel_lvds->pfit_dirty)
-		intel_lvds_disable(intel_lvds);
+	intel_lvds_disable(intel_lvds);
 }
 
 static void intel_lvds_commit(struct drm_encoder *encoder)

[ 04/34] MIPS: Expose missing pci_io{map,unmap} declarations

[Greg Kroah-Hartman]

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

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

From: Markos Chandras <markos.chandras@imgtec.com>

commit 78857614104a26cdada4c53eea104752042bf5a1 upstream.

The GENERIC_PCI_IOMAP does not depend on CONFIG_PCI so move
it to the CONFIG_MIPS symbol so it's always selected for MIPS.
This fixes the missing pci_iomap declaration for MIPS.
Moreover, the pci_iounmap function was not defined in the
io.h header file if the CONFIG_PCI symbol is not set,
but it should since MIPS is not using CONFIG_GENERIC_IOMAP.

This fixes the following problem on a allyesconfig:

drivers/net/ethernet/3com/3c59x.c:1031:2: error: implicit declaration of
function 'pci_iomap' [-Werror=implicit-function-declaration]
drivers/net/ethernet/3com/3c59x.c:1044:3: error: implicit declaration of
function 'pci_iounmap' [-Werror=implicit-function-declaration]

Signed-off-by: Markos Chandras <markos.chandras@imgtec.com>
Acked-by: Steven J. Hill <Steven.Hill@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/5478/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Cc: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 arch/mips/Kconfig          |    2 +-
 arch/mips/include/asm/io.h |    5 +++++
 2 files changed, 6 insertions(+), 1 deletion(-)

--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -24,6 +24,7 @@ config MIPS
 	select HAVE_GENERIC_HARDIRQS
 	select GENERIC_IRQ_PROBE
 	select GENERIC_IRQ_SHOW
+	select GENERIC_PCI_IOMAP
 	select HAVE_ARCH_JUMP_LABEL
 	select IRQ_FORCED_THREADING
 	select HAVE_MEMBLOCK
@@ -2356,7 +2357,6 @@ config PCI
 	bool "Support for PCI controller"
 	depends on HW_HAS_PCI
 	select PCI_DOMAINS
-	select GENERIC_PCI_IOMAP
 	select NO_GENERIC_PCI_IOPORT_MAP
 	help
 	  Find out whether you have a PCI motherboard. PCI is the name of a
--- a/arch/mips/include/asm/io.h
+++ b/arch/mips/include/asm/io.h
@@ -168,6 +168,11 @@ static inline void * isa_bus_to_virt(uns
 extern void __iomem * __ioremap(phys_t offset, phys_t size, unsigned long flags);
 extern void __iounmap(const volatile void __iomem *addr);
 
+#ifndef CONFIG_PCI
+struct pci_dev;
+static inline void pci_iounmap(struct pci_dev *dev, void __iomem *addr) {}
+#endif
+
 static inline void __iomem * __ioremap_mode(phys_t offset, unsigned long size,
 	unsigned long flags)
 {

[ 05/34] microblaze: Update microblaze defconfigs

[Greg Kroah-Hartman]

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

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

From: Michal Simek <michal.simek@xilinx.com>

commit d0e045401f268a8de6f87d65678214748b772680 upstream.

The main reason is 0-day testing system which can directly
use these defconfigs for testing.

Enable support for all xilinx drivers which Microblaze
can use and disable dependency on external rootfs.cpio.
There is only one exception which is axi ethernet driver
which still uses NO_IRQ which is not defined for Microblaze.

Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Cc: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 arch/microblaze/configs/mmu_defconfig   |   49 ++++++++++++++--------
 arch/microblaze/configs/nommu_defconfig |   71 ++++++++++++++++++--------------
 2 files changed, 75 insertions(+), 45 deletions(-)

--- a/arch/microblaze/configs/mmu_defconfig
+++ b/arch/microblaze/configs/mmu_defconfig
@@ -1,25 +1,22 @@
 CONFIG_EXPERIMENTAL=y
 CONFIG_SYSVIPC=y
+CONFIG_POSIX_MQUEUE=y
+CONFIG_FHANDLE=y
+CONFIG_AUDIT=y
+CONFIG_AUDIT_LOGINUID_IMMUTABLE=y
 CONFIG_IKCONFIG=y
 CONFIG_IKCONFIG_PROC=y
+CONFIG_SYSFS_DEPRECATED=y
 CONFIG_SYSFS_DEPRECATED_V2=y
-CONFIG_BLK_DEV_INITRD=y
-CONFIG_INITRAMFS_SOURCE="rootfs.cpio"
-CONFIG_INITRAMFS_COMPRESSION_GZIP=y
-# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
-CONFIG_EXPERT=y
 CONFIG_KALLSYMS_ALL=y
-CONFIG_KALLSYMS_EXTRA_PASS=y
-# CONFIG_HOTPLUG is not set
 # CONFIG_BASE_FULL is not set
-# CONFIG_FUTEX is not set
-# CONFIG_EPOLL is not set
-# CONFIG_SIGNALFD is not set
-# CONFIG_SHMEM is not set
+CONFIG_EMBEDDED=y
 CONFIG_SLAB=y
 CONFIG_MODULES=y
 CONFIG_MODULE_UNLOAD=y
 # CONFIG_BLK_DEV_BSG is not set
+CONFIG_PARTITION_ADVANCED=y
+# CONFIG_EFI_PARTITION is not set
 CONFIG_OPT_LIB_ASM=y
 CONFIG_XILINX_MICROBLAZE0_USE_MSR_INSTR=1
 CONFIG_XILINX_MICROBLAZE0_USE_PCMP_INSTR=1
@@ -37,33 +34,53 @@ CONFIG_UNIX=y
 CONFIG_INET=y
 # CONFIG_INET_LRO is not set
 # CONFIG_IPV6 is not set
+CONFIG_MTD=y
 CONFIG_PROC_DEVICETREE=y
 CONFIG_BLK_DEV_RAM=y
 CONFIG_BLK_DEV_RAM_SIZE=8192
 CONFIG_NETDEVICES=y
-CONFIG_NET_ETHERNET=y
 CONFIG_XILINX_EMACLITE=y
+CONFIG_XILINX_LL_TEMAC=y
 # CONFIG_INPUT is not set
 # CONFIG_SERIO is not set
 # CONFIG_VT is not set
+CONFIG_SERIAL_8250=y
+CONFIG_SERIAL_8250_CONSOLE=y
 CONFIG_SERIAL_UARTLITE=y
 CONFIG_SERIAL_UARTLITE_CONSOLE=y
 # CONFIG_HW_RANDOM is not set
+CONFIG_XILINX_HWICAP=y
+CONFIG_I2C=y
+CONFIG_I2C_XILINX=y
+CONFIG_SPI=y
+CONFIG_SPI_XILINX=y
+CONFIG_GPIOLIB=y
+CONFIG_GPIO_SYSFS=y
+CONFIG_GPIO_XILINX=y
 # CONFIG_HWMON is not set
+CONFIG_WATCHDOG=y
+CONFIG_XILINX_WATCHDOG=y
+CONFIG_FB=y
+CONFIG_FB_XILINX=y
 # CONFIG_USB_SUPPORT is not set
+CONFIG_UIO=y
+CONFIG_UIO_PDRV=y
+CONFIG_UIO_PDRV_GENIRQ=y
+CONFIG_UIO_DMEM_GENIRQ=y
 CONFIG_EXT2_FS=y
 # CONFIG_DNOTIFY is not set
+CONFIG_CRAMFS=y
+CONFIG_ROMFS_FS=y
 CONFIG_NFS_FS=y
-CONFIG_NFS_V3=y
 CONFIG_CIFS=y
 CONFIG_CIFS_STATS=y
 CONFIG_CIFS_STATS2=y
-CONFIG_PARTITION_ADVANCED=y
-CONFIG_DEBUG_KERNEL=y
 CONFIG_DETECT_HUNG_TASK=y
 CONFIG_DEBUG_SLAB=y
 CONFIG_DEBUG_SPINLOCK=y
 CONFIG_DEBUG_INFO=y
-# CONFIG_RCU_CPU_STALL_DETECTOR is not set
 CONFIG_EARLY_PRINTK=y
+CONFIG_KEYS=y
+CONFIG_ENCRYPTED_KEYS=y
+CONFIG_KEYS_DEBUG_PROC_KEYS=y
 # CONFIG_CRYPTO_ANSI_CPRNG is not set
--- a/arch/microblaze/configs/nommu_defconfig
+++ b/arch/microblaze/configs/nommu_defconfig
@@ -1,41 +1,40 @@
 CONFIG_EXPERIMENTAL=y
 CONFIG_SYSVIPC=y
 CONFIG_POSIX_MQUEUE=y
+CONFIG_FHANDLE=y
+CONFIG_AUDIT=y
+CONFIG_AUDIT_LOGINUID_IMMUTABLE=y
 CONFIG_BSD_PROCESS_ACCT=y
 CONFIG_BSD_PROCESS_ACCT_V3=y
 CONFIG_IKCONFIG=y
 CONFIG_IKCONFIG_PROC=y
+CONFIG_SYSFS_DEPRECATED=y
 CONFIG_SYSFS_DEPRECATED_V2=y
-CONFIG_EXPERT=y
 CONFIG_KALLSYMS_ALL=y
-CONFIG_KALLSYMS_EXTRA_PASS=y
-# CONFIG_HOTPLUG is not set
 # CONFIG_BASE_FULL is not set
+CONFIG_EMBEDDED=y
 CONFIG_SLAB=y
 CONFIG_MODULES=y
 CONFIG_MODULE_UNLOAD=y
 # CONFIG_BLK_DEV_BSG is not set
-# CONFIG_OPT_LIB_FUNCTION is not set
+CONFIG_PARTITION_ADVANCED=y
+# CONFIG_EFI_PARTITION is not set
 CONFIG_XILINX_MICROBLAZE0_USE_MSR_INSTR=1
 CONFIG_XILINX_MICROBLAZE0_USE_PCMP_INSTR=1
 CONFIG_XILINX_MICROBLAZE0_USE_BARREL=1
 CONFIG_XILINX_MICROBLAZE0_USE_DIV=1
 CONFIG_XILINX_MICROBLAZE0_USE_HW_MUL=2
 CONFIG_XILINX_MICROBLAZE0_USE_FPU=2
-CONFIG_HIGH_RES_TIMERS=y
 CONFIG_HZ_100=y
 CONFIG_CMDLINE_BOOL=y
-CONFIG_BINFMT_FLAT=y
+CONFIG_CMDLINE_FORCE=y
 CONFIG_NET=y
 CONFIG_PACKET=y
 CONFIG_UNIX=y
 CONFIG_INET=y
 # CONFIG_INET_LRO is not set
 # CONFIG_IPV6 is not set
-# CONFIG_PREVENT_FIRMWARE_BUILD is not set
 CONFIG_MTD=y
-CONFIG_MTD_CONCAT=y
-CONFIG_MTD_PARTITIONS=y
 CONFIG_MTD_CMDLINE_PARTS=y
 CONFIG_MTD_CHAR=y
 CONFIG_MTD_BLOCK=y
@@ -45,41 +44,55 @@ CONFIG_MTD_CFI_AMDSTD=y
 CONFIG_MTD_RAM=y
 CONFIG_MTD_UCLINUX=y
 CONFIG_PROC_DEVICETREE=y
-CONFIG_BLK_DEV_NBD=y
 CONFIG_BLK_DEV_RAM=y
+CONFIG_BLK_DEV_RAM_SIZE=8192
 CONFIG_NETDEVICES=y
-CONFIG_NET_ETHERNET=y
+CONFIG_XILINX_EMACLITE=y
+CONFIG_XILINX_LL_TEMAC=y
 # CONFIG_INPUT is not set
 # CONFIG_SERIO is not set
 # CONFIG_VT is not set
+CONFIG_SERIAL_8250=y
+CONFIG_SERIAL_8250_CONSOLE=y
 CONFIG_SERIAL_UARTLITE=y
 CONFIG_SERIAL_UARTLITE_CONSOLE=y
-CONFIG_HW_RANDOM=y
+# CONFIG_HW_RANDOM is not set
+CONFIG_XILINX_HWICAP=y
+CONFIG_I2C=y
+CONFIG_I2C_XILINX=y
+CONFIG_SPI=y
+CONFIG_SPI_XILINX=y
+CONFIG_GPIOLIB=y
+CONFIG_GPIO_SYSFS=y
+CONFIG_GPIO_XILINX=y
 # CONFIG_HWMON is not set
-CONFIG_VIDEO_OUTPUT_CONTROL=y
+CONFIG_WATCHDOG=y
+CONFIG_XILINX_WATCHDOG=y
+CONFIG_FB=y
+CONFIG_FB_XILINX=y
+# CONFIG_USB_SUPPORT is not set
+CONFIG_UIO=y
+CONFIG_UIO_PDRV=y
+CONFIG_UIO_PDRV_GENIRQ=y
+CONFIG_UIO_DMEM_GENIRQ=y
 CONFIG_EXT2_FS=y
 # CONFIG_DNOTIFY is not set
 CONFIG_CRAMFS=y
 CONFIG_ROMFS_FS=y
 CONFIG_NFS_FS=y
-CONFIG_NFS_V3=y
 CONFIG_NFS_V3_ACL=y
-CONFIG_UNUSED_SYMBOLS=y
-CONFIG_DEBUG_FS=y
-CONFIG_DEBUG_KERNEL=y
-CONFIG_DEBUG_SHIRQ=y
+CONFIG_NLS=y
 CONFIG_DETECT_HUNG_TASK=y
-CONFIG_SCHEDSTATS=y
-CONFIG_TIMER_STATS=y
-CONFIG_DEBUG_OBJECTS=y
-CONFIG_DEBUG_OBJECTS_SELFTEST=y
-CONFIG_DEBUG_OBJECTS_FREE=y
-CONFIG_DEBUG_OBJECTS_TIMERS=y
+CONFIG_DEBUG_SLAB=y
+CONFIG_DEBUG_SPINLOCK=y
 CONFIG_DEBUG_INFO=y
-CONFIG_DEBUG_LIST=y
-CONFIG_DEBUG_SG=y
-# CONFIG_RCU_CPU_STALL_DETECTOR is not set
-CONFIG_SYSCTL_SYSCALL_CHECK=y
 CONFIG_EARLY_PRINTK=y
+CONFIG_KEYS=y
+CONFIG_ENCRYPTED_KEYS=y
+CONFIG_KEYS_DEBUG_PROC_KEYS=y
+CONFIG_CRYPTO_ECB=y
+CONFIG_CRYPTO_MD4=y
+CONFIG_CRYPTO_MD5=y
+CONFIG_CRYPTO_ARC4=y
+CONFIG_CRYPTO_DES=y
 # CONFIG_CRYPTO_ANSI_CPRNG is not set
-# CONFIG_CRC32 is not set

[ 06/34] sound: Fix make allmodconfig on MIPS

[Greg Kroah-Hartman]

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

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

From: Takashi Iwai <tiwai@suse.de>

commit d4702b189c6b951c1cb3260036ff998f719bfb62 upstream.

The compile of soundcard.c is broken on MIPS when allmodconfig is used
because of the missing MAX_DMA_CHANNELS definition.  As a simple
workaround, just add a Kconfig dependency.

Reported-by: Andrew Morton <akpm@linux-foundation.org>
Cc: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Cc: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 sound/oss/Kconfig |    1 +
 1 file changed, 1 insertion(+)

--- a/sound/oss/Kconfig
+++ b/sound/oss/Kconfig
@@ -250,6 +250,7 @@ config MSND_FIFOSIZE
 menuconfig SOUND_OSS
 	tristate "OSS sound modules"
 	depends on ISA_DMA_API && VIRT_TO_BUS
+	depends on !ISA_DMA_SUPPORT_BROKEN
 	help
 	  OSS is the Open Sound System suite of sound card drivers.  They make
 	  sound programming easier since they provide a common API.  Say Y or

[ 07/34] sound: Fix make allmodconfig on MIPS correctly

[Greg Kroah-Hartman]

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

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

From: Paul Bolle <pebolle@tiscali.nl>

commit a62ee234a572b4c98fe98cf5fb18e4e8b0f6e43d upstream.

Commit d4702b189c ("sound: Fix make allmodconfig on MIPS") added a
(negative) dependency on ISA_DMA_SUPPORT_BROKEN. Since that Kconfig
symbol doesn't exist, this dependency will always evaluate to true.
Apparently GENERIC_ISA_DMA_SUPPORT_BROKEN was meant to be used here.

Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Cc: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 sound/oss/Kconfig |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/sound/oss/Kconfig
+++ b/sound/oss/Kconfig
@@ -250,7 +250,7 @@ config MSND_FIFOSIZE
 menuconfig SOUND_OSS
 	tristate "OSS sound modules"
 	depends on ISA_DMA_API && VIRT_TO_BUS
-	depends on !ISA_DMA_SUPPORT_BROKEN
+	depends on !GENERIC_ISA_DMA_SUPPORT_BROKEN
 	help
 	  OSS is the Open Sound System suite of sound card drivers.  They make
 	  sound programming easier since they provide a common API.  Say Y or

[ 08/34] HID: microsoft: do not use compound literal - fix build

[Greg Kroah-Hartman]

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

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

From: Jiri Slaby <jslaby@suse.cz>

commit 6b90466cfec2a2fe027187d675d8d14217c12d82 upstream.

In patch "HID: microsoft: fix invalid rdesc for 3k kbd" I fixed
support for MS 3k keyboards. However the added check using memcmp and
a compound statement breaks build on architectures where memcmp is a
macro with parameters.

hid-microsoft.c:51:18: error: macro "memcmp" passed 6 arguments, but takes just 3

On x86_64, memcmp is a function, so I did not see the error.

Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Cc: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/hid/hid-microsoft.c |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

--- a/drivers/hid/hid-microsoft.c
+++ b/drivers/hid/hid-microsoft.c
@@ -47,9 +47,9 @@ static __u8 *ms_report_fixup(struct hid_
 		rdesc[559] = 0x45;
 	}
 	/* the same as above (s/usage/physical/) */
-	if ((quirks & MS_RDESC_3K) && *rsize == 106 &&
-			!memcmp((char []){ 0x19, 0x00, 0x29, 0xff },
-				&rdesc[94], 4)) {
+	if ((quirks & MS_RDESC_3K) && *rsize == 106 && rdesc[94] == 0x19 &&
+			rdesc[95] == 0x00 && rdesc[96] == 0x29 &&
+			rdesc[97] == 0xff) {
 		rdesc[94] = 0x35;
 		rdesc[96] = 0x45;
 	}

[ 09/34] vm: add no-mmu vm_iomap_memory() stub

[Greg Kroah-Hartman]

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

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

From: Linus Torvalds <torvalds@linux-foundation.org>

commit 3c0b9de6d37a481673e81001c57ca0e410c72346 upstream.

I think we could just move the full vm_iomap_memory() function into
util.h or similar, but I didn't get any reply from anybody actually
using nommu even to this trivial patch, so I'm not going to touch it any
more than required.

Here's the fairly minimal stub to make the nommu case at least
potentially work.  It doesn't seem like anybody cares, though.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 mm/nommu.c |   10 ++++++++++
 1 file changed, 10 insertions(+)

--- a/mm/nommu.c
+++ b/mm/nommu.c
@@ -1856,6 +1856,16 @@ int remap_pfn_range(struct vm_area_struc
 }
 EXPORT_SYMBOL(remap_pfn_range);
 
+int vm_iomap_memory(struct vm_area_struct *vma, phys_addr_t start, unsigned long len)
+{
+	unsigned long pfn = start >> PAGE_SHIFT;
+	unsigned long vm_len = vma->vm_end - vma->vm_start;
+
+	pfn += vma->vm_pgoff;
+	return io_remap_pfn_range(vma, vma->vm_start, pfn, vm_len, vma->vm_page_prot);
+}
+EXPORT_SYMBOL(vm_iomap_memory);
+
 int remap_vmalloc_range(struct vm_area_struct *vma, void *addr,
 			unsigned long pgoff)
 {

[ 10/34] cris: posix_types.h, include asm-generic/posix_types.h

[Greg Kroah-Hartman]

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

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

From: Jiri Slaby <jslaby@suse.cz>

commit 74f077d2a7651409c44bb323471f219a4b0d2aab upstream.

Without that I cannot build anything:
In file included from include/linux/page-flags.h:8:0,
                 from kernel/bounds.c:9:
include/linux/types.h:25:1: error: unknown type name '__kernel_ino_t'
include/linux/types.h:29:1: error: unknown type name '__kernel_off_t'
...

Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Cc: Mikael Starvik <starvik@axis.com>
Signed-off-by: Jesper Nilsson <jesper.nilsson@axis.com>
Cc: linux-cris-kernel@axis.com
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 arch/cris/include/asm/posix_types.h |    2 ++
 1 file changed, 2 insertions(+)

--- a/arch/cris/include/asm/posix_types.h
+++ b/arch/cris/include/asm/posix_types.h
@@ -33,4 +33,6 @@ typedef int		__kernel_ptrdiff_t;
 typedef unsigned short	__kernel_old_dev_t;
 #define __kernel_old_dev_t __kernel_old_dev_t
 
+#include <asm-generic/posix_types.h>
+
 #endif /* __ARCH_CRIS_POSIX_TYPES_H */

[ 11/34] cris: Remove old legacy "-traditional" flag from arch-v10/lib/Makefile

[Greg Kroah-Hartman]

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

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

From: Paul Gortmaker <paul.gortmaker@windriver.com>

commit 7b91747d42a1012e3781dd09fa638d113809e3fd upstream.

Most of these have been purged years ago.  This one silently lived
on until commit 69349c2dc01c489eccaa4c472542c08e370c6d7e

    "kconfig: fix IS_ENABLED to not require all options to be defined"

In the above, we use some macro trickery to create a conditional that
is valid in CPP and in C usage.  However that trickery doesn't sit
well if you have the legacy "-traditional" flag enabled.  You'll get:

  AS      arch/cris/arch-v10/lib/checksum.o
In file included from <command-line>:4:0:
include/linux/kconfig.h:23:0: error: syntax error in macro parameter list
make[2]: *** [arch/cris/arch-v10/lib/checksum.o] Error 1

Everything builds fine w/o "-traditional" so simply drop it from this
location as well.

Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Jesper Nilsson <jesper.nilsson@axis.com>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 arch/cris/arch-v10/lib/Makefile |    3 ---
 1 file changed, 3 deletions(-)

--- a/arch/cris/arch-v10/lib/Makefile
+++ b/arch/cris/arch-v10/lib/Makefile
@@ -2,8 +2,5 @@
 # Makefile for Etrax-specific library files..
 #
 
-
-EXTRA_AFLAGS := -traditional
-
 lib-y  = checksum.o checksumcopy.o string.o usercopy.o memset.o csumcpfruser.o
 

[ 12/34] CRIS: Add _sdata to vmlinux.lds.S

[Greg Kroah-Hartman]

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

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

From: Jesper Nilsson <jesper.nilsson@axis.com>

commit 473e162eea465e60578edb93341752e7f1c1dacc upstream.

Fixes link error:
  LD      vmlinux
kernel/built-in.o: In function `core_kernel_data':
(.text+0x13e44): undefined reference to `_sdata'

Signed-off-by: Jesper Nilsson <jesper.nilsson@axis.com>
Cc: Guenter Roeck <linux@roeck-us.net>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 arch/cris/kernel/vmlinux.lds.S |    1 +
 1 file changed, 1 insertion(+)

--- a/arch/cris/kernel/vmlinux.lds.S
+++ b/arch/cris/kernel/vmlinux.lds.S
@@ -52,6 +52,7 @@ SECTIONS
 
 	EXCEPTION_TABLE(4)
 
+	_sdata = .;
 	RODATA
 
 	. = ALIGN (4);

[ 13/34] futex: Take hugepages into account when generating futex_key

[Greg Kroah-Hartman]

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

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

From: Zhang Yi <wetpzy@gmail.com>

commit 13d60f4b6ab5b702dc8d2ee20999f98a93728aec upstream.

The futex_keys of process shared futexes are generated from the page
offset, the mapping host and the mapping index of the futex user space
address. This should result in an unique identifier for each futex.

Though this is not true when futexes are located in different subpages
of an hugepage. The reason is, that the mapping index for all those
futexes evaluates to the index of the base page of the hugetlbfs
mapping. So a futex at offset 0 of the hugepage mapping and another
one at offset PAGE_SIZE of the same hugepage mapping have identical
futex_keys. This happens because the futex code blindly uses
page->index.

Steps to reproduce the bug:

1. Map a file from hugetlbfs. Initialize pthread_mutex1 at offset 0
   and pthread_mutex2 at offset PAGE_SIZE of the hugetlbfs
   mapping.

   The mutexes must be initialized as PTHREAD_PROCESS_SHARED because
   PTHREAD_PROCESS_PRIVATE mutexes are not affected by this issue as
   their keys solely depend on the user space address.

2. Lock mutex1 and mutex2

3. Create thread1 and in the thread function lock mutex1, which
   results in thread1 blocking on the locked mutex1.

4. Create thread2 and in the thread function lock mutex2, which
   results in thread2 blocking on the locked mutex2.

5. Unlock mutex2. Despite the fact that mutex2 got unlocked, thread2
   still blocks on mutex2 because the futex_key points to mutex1.

To solve this issue we need to take the normal page index of the page
which contains the futex into account, if the futex is in an hugetlbfs
mapping. In other words, we calculate the normal page mapping index of
the subpage in the hugetlbfs mapping.

Mappings which are not based on hugetlbfs are not affected and still
use page->index.

Thanks to Mel Gorman who provided a patch for adding proper evaluation
functions to the hugetlbfs code to avoid exposing hugetlbfs specific
details to the futex code.

[ tglx: Massaged changelog ]

Signed-off-by: Zhang Yi <zhang.yi20@zte.com.cn>
Reviewed-by: Jiang Biao <jiang.biao2@zte.com.cn>
Tested-by: Ma Chenggong <ma.chenggong@zte.com.cn>
Reviewed-by: 'Mel Gorman' <mgorman@suse.de>
Acked-by: 'Darren Hart' <dvhart@linux.intel.com>
Cc: 'Peter Zijlstra' <peterz@infradead.org>
Link: http://lkml.kernel.org/r/000101ce71a6%24a83c5880%24f8b50980%24@com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Mike Galbraith <mgalbraith@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>


---
 include/linux/hugetlb.h |   16 ++++++++++++++++
 kernel/futex.c          |    3 ++-
 mm/hugetlb.c            |   17 +++++++++++++++++
 3 files changed, 35 insertions(+), 1 deletion(-)

--- a/include/linux/hugetlb.h
+++ b/include/linux/hugetlb.h
@@ -293,6 +293,17 @@ static inline unsigned hstate_index_to_s
 	return hstates[index].order + PAGE_SHIFT;
 }
 
+pgoff_t __basepage_index(struct page *page);
+
+/* Return page->index in PAGE_SIZE units */
+static inline pgoff_t basepage_index(struct page *page)
+{
+	if (!PageCompound(page))
+		return page->index;
+
+	return __basepage_index(page);
+}
+
 #else	/* CONFIG_HUGETLB_PAGE */
 struct hstate {};
 #define alloc_huge_page_node(h, nid) NULL
@@ -311,6 +322,11 @@ static inline unsigned int pages_per_hug
 	return 1;
 }
 #define hstate_index_to_shift(index) 0
+
+static inline pgoff_t basepage_index(struct page *page)
+{
+	return page->index;
+}
 #endif
 
 #endif /* _LINUX_HUGETLB_H */
--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -60,6 +60,7 @@
 #include <linux/pid.h>
 #include <linux/nsproxy.h>
 #include <linux/ptrace.h>
+#include <linux/hugetlb.h>
 
 #include <asm/futex.h>
 
@@ -363,7 +364,7 @@ again:
 	} else {
 		key->both.offset |= FUT_OFF_INODE; /* inode-based key */
 		key->shared.inode = page_head->mapping->host;
-		key->shared.pgoff = page_head->index;
+		key->shared.pgoff = basepage_index(page);
 	}
 
 	get_futex_key_refs(key);
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -679,6 +679,23 @@ int PageHuge(struct page *page)
 }
 EXPORT_SYMBOL_GPL(PageHuge);
 
+pgoff_t __basepage_index(struct page *page)
+{
+	struct page *page_head = compound_head(page);
+	pgoff_t index = page_index(page_head);
+	unsigned long compound_idx;
+
+	if (!PageHuge(page_head))
+		return page_index(page);
+
+	if (compound_order(page_head) >= MAX_ORDER)
+		compound_idx = page_to_pfn(page) - page_to_pfn(page_head);
+	else
+		compound_idx = page - page_head;
+
+	return (index << compound_order(page_head)) + compound_idx;
+}
+
 static struct page *alloc_fresh_huge_page_node(struct hstate *h, int nid)
 {
 	struct page *page;

[ 14/34] frv: Use correct size for task_struct allocation

[Greg Kroah-Hartman]

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

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

From: Thomas Gleixner <tglx@linutronix.de>

commit cce4517f33384c3794c759e206cc8e1bb6df146b upstream.

alloc_task_struct_node() allocates THREAD_SIZE and maintains some
weird refcount in the allocated memory. This never blew up as
task_struct size on 32bit machines was always less than THREAD_SIZE

Allocate just sizeof(struct task_struct) and get rid of the magic
refcounting.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: David Howells <dhowells@redhat.com>
Link: http://lkml.kernel.org/r/20120503085033.898475542@linutronix.de
Cc: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 arch/frv/kernel/process.c |    9 ++-------
 1 file changed, 2 insertions(+), 7 deletions(-)

--- a/arch/frv/kernel/process.c
+++ b/arch/frv/kernel/process.c
@@ -46,17 +46,12 @@ EXPORT_SYMBOL(pm_power_off);
 
 struct task_struct *alloc_task_struct_node(int node)
 {
-	struct task_struct *p = kmalloc_node(THREAD_SIZE, GFP_KERNEL, node);
-
-	if (p)
-		atomic_set((atomic_t *)(p+1), 1);
-	return p;
+	return kmalloc_node(sizeof(task_struct), GFP_KERNEL, node);
 }
 
 void free_task_struct(struct task_struct *p)
 {
-	if (atomic_dec_and_test((atomic_t *)(p+1)))
-		kfree(p);
+	kfree(p);
 }
 
 static void core_sleep_idle(void)

[ 15/34] frv: Use core allocator for task_struct

[Greg Kroah-Hartman]

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

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

From: Thomas Gleixner <tglx@linutronix.de>

commit c6ae063aaf3786b9db7f19a90bf4ed8aaebb7f90 upstream.

There is no point having a copy of the core allocator.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: David Howells <dhowells@redhat.com>
Link: http://lkml.kernel.org/r/20120503085033.967140188@linutronix.de
Cc: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 arch/frv/include/asm/thread_info.h |    2 --
 arch/frv/kernel/process.c          |   10 ----------
 2 files changed, 12 deletions(-)

--- a/arch/frv/include/asm/thread_info.h
+++ b/arch/frv/include/asm/thread_info.h
@@ -21,8 +21,6 @@
 
 #define THREAD_SIZE		8192
 
-#define __HAVE_ARCH_TASK_STRUCT_ALLOCATOR
-
 /*
  * low level task data that entry.S needs immediate access to
  * - this struct should fit entirely inside of one cache line
--- a/arch/frv/kernel/process.c
+++ b/arch/frv/kernel/process.c
@@ -44,16 +44,6 @@ asmlinkage void ret_from_fork(void);
 void (*pm_power_off)(void);
 EXPORT_SYMBOL(pm_power_off);
 
-struct task_struct *alloc_task_struct_node(int node)
-{
-	return kmalloc_node(sizeof(task_struct), GFP_KERNEL, node);
-}
-
-void free_task_struct(struct task_struct *p)
-{
-	kfree(p);
-}
-
 static void core_sleep_idle(void)
 {
 #ifdef LED_DEBUG_SLEEP

[ 16/34] powerpc/numa: Avoid stupid uninitialized warning from gcc

[Greg Kroah-Hartman]

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

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

From: Benjamin Herrenschmidt <benh@kernel.crashing.org>

commit aa709f3bc92c6daaf177cd7e3446da2ef64426c6 upstream.

Newer gcc are being a bit blind here (it's pretty obvious we don't
reach the code path using the array if we haven't initialized the
pointer) but none of that is performance critical so let's just
silence it.

Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 arch/powerpc/mm/numa.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/arch/powerpc/mm/numa.c
+++ b/arch/powerpc/mm/numa.c
@@ -639,7 +639,7 @@ static void __init parse_drconf_memory(s
 	unsigned int n, rc, ranges, is_kexec_kdump = 0;
 	unsigned long lmb_size, base, size, sz;
 	int nid;
-	struct assoc_arrays aa;
+	struct assoc_arrays aa = { .arrays = NULL };
 
 	n = of_get_drconf_memory(memory, &dm);
 	if (!n)

[ 17/34] alpha: makefile: dont enforce small data model for kernel builds

[Greg Kroah-Hartman]

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

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

From: Will Deacon <will.deacon@arm.com>

commit cd8d2331756751b6aeb855a3c9cb0a92fbd9c725 upstream.

Due to all of the goodness being packed into today's kernels, the
resulting image isn't as slim as it once was.

In light of this, don't pass -msmall-data to gcc, which otherwise results
in link failures due to impossible relocations when compiling anything but
the most trivial configurations.

Reviewed-by: Matt Turner <mattst88@gmail.com>
Cc: Richard Henderson <rth@twiddle.net>
Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
Tested-by: Thorsten Kranzkowski <dl8bcu@dl8bcu.de>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Michael Cree <mcree@orcon.net.nz>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 arch/alpha/Makefile |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/arch/alpha/Makefile
+++ b/arch/alpha/Makefile
@@ -12,7 +12,7 @@ NM := $(NM) -B
 
 LDFLAGS_vmlinux	:= -static -N #-relax
 CHECKFLAGS	+= -D__alpha__ -m64
-cflags-y	:= -pipe -mno-fp-regs -ffixed-8 -msmall-data
+cflags-y	:= -pipe -mno-fp-regs -ffixed-8
 cflags-y	+= $(call cc-option, -fno-jump-tables)
 
 cpuflags-$(CONFIG_ALPHA_EV4)		:= -mcpu=ev4

[ 18/34] md/raid1,raid10: use freeze_array in place of raise_barrier in various places.

[Greg Kroah-Hartman]

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

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

From: NeilBrown <neilb@suse.de>

commit e2d59925221cd562e07fee38ec8839f7209ae603 upstream.

Various places in raid1 and raid10 are calling raise_barrier when they
really should call freeze_array.
The former is only intended to be called from "make_request".
The later has extra checks for 'nr_queued' and makes a call to
flush_pending_writes(), so it is safe to call it from within the
management thread.

Using raise_barrier will sometimes deadlock.  Using freeze_array
should not.

As 'freeze_array' currently expects one request to be pending (in
handle_read_error - the only previous caller), we need to pass
it the number of pending requests (extra) to ignore.

The deadlock was made particularly noticeable by commits
050b66152f87c7 (raid10) and 6b740b8d79252f13 (raid1) which
appeared in 3.4, so the fix is appropriate for any -stable
kernel since then.

This patch probably won't apply directly to some early kernels and
will need to be applied by hand.

Cc: stable@vger.kernel.org
Reported-by: Alexander Lyakas <alex.bolshoy@gmail.com>
Signed-off-by: NeilBrown <neilb@suse.de>
[adjust context to make it can be apply on top of 3.4 ]
Signed-off-by: Jack Wang <jinpu.wang@profitbricks.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/md/raid1.c  |   22 +++++++++++-----------
 drivers/md/raid10.c |   14 +++++++-------
 2 files changed, 18 insertions(+), 18 deletions(-)

--- a/drivers/md/raid1.c
+++ b/drivers/md/raid1.c
@@ -812,17 +812,17 @@ static void allow_barrier(struct r1conf
 	wake_up(&conf->wait_barrier);
 }
 
-static void freeze_array(struct r1conf *conf)
+static void freeze_array(struct r1conf *conf, int extra)
 {
 	/* stop syncio and normal IO and wait for everything to
 	 * go quite.
 	 * We increment barrier and nr_waiting, and then
-	 * wait until nr_pending match nr_queued+1
+	 * wait until nr_pending match nr_queued+extra
 	 * This is called in the context of one normal IO request
 	 * that has failed. Thus any sync request that might be pending
 	 * will be blocked by nr_pending, and we need to wait for
 	 * pending IO requests to complete or be queued for re-try.
-	 * Thus the number queued (nr_queued) plus this request (1)
+	 * Thus the number queued (nr_queued) plus this request (extra)
 	 * must match the number of pending IOs (nr_pending) before
 	 * we continue.
 	 */
@@ -830,7 +830,7 @@ static void freeze_array(struct r1conf *
 	conf->barrier++;
 	conf->nr_waiting++;
 	wait_event_lock_irq(conf->wait_barrier,
-			    conf->nr_pending == conf->nr_queued+1,
+			    conf->nr_pending == conf->nr_queued+extra,
 			    conf->resync_lock,
 			    flush_pending_writes(conf));
 	spin_unlock_irq(&conf->resync_lock);
@@ -1432,8 +1432,8 @@ static int raid1_add_disk(struct mddev *
 		 * we wait for all outstanding requests to complete.
 		 */
 		synchronize_sched();
-		raise_barrier(conf);
-		lower_barrier(conf);
+		freeze_array(conf, 0);
+		unfreeze_array(conf);
 		clear_bit(Unmerged, &rdev->flags);
 	}
 	md_integrity_add_rdev(rdev, mddev);
@@ -1481,11 +1481,11 @@ static int raid1_remove_disk(struct mdde
 			 */
 			struct md_rdev *repl =
 				conf->mirrors[conf->raid_disks + number].rdev;
-			raise_barrier(conf);
+			freeze_array(conf, 0);
 			clear_bit(Replacement, &repl->flags);
 			p->rdev = repl;
 			conf->mirrors[conf->raid_disks + number].rdev = NULL;
-			lower_barrier(conf);
+			unfreeze_array(conf);
 			clear_bit(WantReplacement, &rdev->flags);
 		} else
 			clear_bit(WantReplacement, &rdev->flags);
@@ -2100,7 +2100,7 @@ static void handle_read_error(struct r1c
 	 * frozen
 	 */
 	if (mddev->ro == 0) {
-		freeze_array(conf);
+		freeze_array(conf, 1);
 		fix_read_error(conf, r1_bio->read_disk,
 			       r1_bio->sector, r1_bio->sectors);
 		unfreeze_array(conf);
@@ -2855,7 +2855,7 @@ static int raid1_reshape(struct mddev *m
 		return -ENOMEM;
 	}
 
-	raise_barrier(conf);
+	freeze_array(conf, 0);
 
 	/* ok, everything is stopped */
 	oldpool = conf->r1bio_pool;
@@ -2887,7 +2887,7 @@ static int raid1_reshape(struct mddev *m
 	mddev->delta_disks = 0;
 
 	conf->last_used = 0; /* just make sure it is in-range */
-	lower_barrier(conf);
+	unfreeze_array(conf);
 
 	set_bit(MD_RECOVERY_NEEDED, &mddev->recovery);
 	md_wakeup_thread(mddev->thread);
--- a/drivers/md/raid10.c
+++ b/drivers/md/raid10.c
@@ -952,17 +952,17 @@ static void allow_barrier(struct r10conf
 	wake_up(&conf->wait_barrier);
 }
 
-static void freeze_array(struct r10conf *conf)
+static void freeze_array(struct r10conf *conf, int extra)
 {
 	/* stop syncio and normal IO and wait for everything to
 	 * go quiet.
 	 * We increment barrier and nr_waiting, and then
-	 * wait until nr_pending match nr_queued+1
+	 * wait until nr_pending match nr_queued+extra
 	 * This is called in the context of one normal IO request
 	 * that has failed. Thus any sync request that might be pending
 	 * will be blocked by nr_pending, and we need to wait for
 	 * pending IO requests to complete or be queued for re-try.
-	 * Thus the number queued (nr_queued) plus this request (1)
+	 * Thus the number queued (nr_queued) plus this request (extra)
 	 * must match the number of pending IOs (nr_pending) before
 	 * we continue.
 	 */
@@ -970,7 +970,7 @@ static void freeze_array(struct r10conf
 	conf->barrier++;
 	conf->nr_waiting++;
 	wait_event_lock_irq(conf->wait_barrier,
-			    conf->nr_pending == conf->nr_queued+1,
+			    conf->nr_pending == conf->nr_queued+extra,
 			    conf->resync_lock,
 			    flush_pending_writes(conf));
 
@@ -1619,8 +1619,8 @@ static int raid10_add_disk(struct mddev
 		 * we wait for all outstanding requests to complete.
 		 */
 		synchronize_sched();
-		raise_barrier(conf, 0);
-		lower_barrier(conf);
+		freeze_array(conf, 0);
+		unfreeze_array(conf);
 		clear_bit(Unmerged, &rdev->flags);
 	}
 	md_integrity_add_rdev(rdev, mddev);
@@ -2410,7 +2410,7 @@ static void handle_read_error(struct mdd
 	r10_bio->devs[slot].bio = NULL;
 
 	if (mddev->ro == 0) {
-		freeze_array(conf);
+		freeze_array(conf, 1);
 		fix_read_error(conf, mddev, r10_bio);
 		unfreeze_array(conf);
 	} else

[ 19/34] sparc32: add ucmpdi2

[Greg Kroah-Hartman]

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

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

From: Sam Ravnborg <sam@ravnborg.org>

commit de36e66d5fa52bc6e2dacd95c701a1762b5308a7 upstream.

Based on copy from microblaze add ucmpdi2 implementation.
This fixes build of niu driver which failed with:

drivers/built-in.o: In function `niu_get_nfc':
niu.c:(.text+0x91494): undefined reference to `__ucmpdi2'

This driver will never be used on a sparc32 system,
but patch added to fix build breakage with all*config builds.

Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Cc: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 arch/sparc/lib/Makefile  |    2 +-
 arch/sparc/lib/ucmpdi2.c |   19 +++++++++++++++++++
 2 files changed, 20 insertions(+), 1 deletion(-)

--- a/arch/sparc/lib/Makefile
+++ b/arch/sparc/lib/Makefile
@@ -15,7 +15,7 @@ lib-$(CONFIG_SPARC32) += divdi3.o udivdi
 lib-$(CONFIG_SPARC32) += copy_user.o locks.o
 lib-y                 += atomic_$(BITS).o
 lib-$(CONFIG_SPARC32) += lshrdi3.o ashldi3.o
-lib-$(CONFIG_SPARC32) += muldi3.o bitext.o cmpdi2.o
+lib-$(CONFIG_SPARC32) += muldi3.o bitext.o cmpdi2.o ucmpdi2.o
 
 lib-$(CONFIG_SPARC64) += copy_page.o clear_page.o bzero.o
 lib-$(CONFIG_SPARC64) += csum_copy.o csum_copy_from_user.o csum_copy_to_user.o
--- /dev/null
+++ b/arch/sparc/lib/ucmpdi2.c
@@ -0,0 +1,19 @@
+#include <linux/module.h>
+#include "libgcc.h"
+
+word_type __ucmpdi2(unsigned long long a, unsigned long long b)
+{
+	const DWunion au = {.ll = a};
+	const DWunion bu = {.ll = b};
+
+	if ((unsigned int) au.s.high < (unsigned int) bu.s.high)
+		return 0;
+	else if ((unsigned int) au.s.high > (unsigned int) bu.s.high)
+		return 2;
+	if ((unsigned int) au.s.low < (unsigned int) bu.s.low)
+		return 0;
+	else if ((unsigned int) au.s.low > (unsigned int) bu.s.low)
+		return 2;
+	return 1;
+}
+EXPORT_SYMBOL(__ucmpdi2);

[ 20/34] sparc32: Add ucmpdi2.o to obj-y instead of lib-y.

[Greg Kroah-Hartman]

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

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

From: "David S. Miller" <davem@davemloft.net>

commit 74c7b28953d4eaa6a479c187aeafcfc0280da5e8 upstream.

Otherwise if no references exist in the static kernel image,
we won't export the symbol properly to modules.

Signed-off-by: David S. Miller <davem@davemloft.net>
Cc: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 arch/sparc/lib/Makefile |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/arch/sparc/lib/Makefile
+++ b/arch/sparc/lib/Makefile
@@ -15,7 +15,7 @@ lib-$(CONFIG_SPARC32) += divdi3.o udivdi
 lib-$(CONFIG_SPARC32) += copy_user.o locks.o
 lib-y                 += atomic_$(BITS).o
 lib-$(CONFIG_SPARC32) += lshrdi3.o ashldi3.o
-lib-$(CONFIG_SPARC32) += muldi3.o bitext.o cmpdi2.o ucmpdi2.o
+lib-$(CONFIG_SPARC32) += muldi3.o bitext.o cmpdi2.o
 
 lib-$(CONFIG_SPARC64) += copy_page.o clear_page.o bzero.o
 lib-$(CONFIG_SPARC64) += csum_copy.o csum_copy_from_user.o csum_copy_to_user.o
@@ -40,7 +40,7 @@ lib-$(CONFIG_SPARC64) += copy_in_user.o
 lib-$(CONFIG_SPARC64) += mcount.o ipcsum.o xor.o hweight.o ffs.o
 
 obj-y                 += iomap.o
-obj-$(CONFIG_SPARC32) += atomic32.o
+obj-$(CONFIG_SPARC32) += atomic32.o ucmpdi2.o
 obj-y                 += ksyms.o
 obj-$(CONFIG_SPARC64) += PeeCeeI.o
 obj-y                 += usercopy.o

[ 21/34] MIPS: Rewrite pfn_valid to work in modules, too.

[Greg Kroah-Hartman]

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

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

From: Ralf Baechle <ralf@linux-mips.org>

Upstream commit 8b9232141bf40788cce31f893c13f344ec31ee66.

This fixes:

  MODPOST 393 modules
ERROR: "min_low_pfn" [arch/mips/kvm/kvm.ko] undefined!
make[3]: *** [__modpost] Error 1

It would have been possible to just export min_low_pfn but in the end
pfn_valid should return 1 for any pfn argument for which a struct page
exists so using min_low_pfn was wrong anyway.

[Backport to 3.4 kernel. Applies cleanly on top of current 3.4 patch queue,
and fixes "make ARCH=mips allmodconfig; make ARCH=mips" build problem. - Guenter]

Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---

 arch/mips/include/asm/page.h |   17 +++++++++--------
 1 file changed, 9 insertions(+), 8 deletions(-)

--- a/arch/mips/include/asm/page.h
+++ b/arch/mips/include/asm/page.h
@@ -175,14 +175,15 @@ typedef struct { unsigned long pgprot; }
 
 #ifdef CONFIG_FLATMEM
 
-#define pfn_valid(pfn)							\
-({									\
-	unsigned long __pfn = (pfn);					\
-	/* avoid <linux/bootmem.h> include hell */			\
-	extern unsigned long min_low_pfn;				\
-									\
-	__pfn >= min_low_pfn && __pfn < max_mapnr;			\
-})
+#ifndef __ASSEMBLY__
+static inline int pfn_valid(unsigned long pfn)
+{
+	/* avoid <linux/mm.h> include hell */
+	extern unsigned long max_mapnr;
+
+	return pfn >= ARCH_PFN_OFFSET && pfn < max_mapnr;
+}
+#endif
 
 #elif defined(CONFIG_SPARSEMEM)
 

[ 22/34] af_key: initialize satype in key_notify_policy_flush()

[Greg Kroah-Hartman]

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

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

From: Nicolas Dichtel <nicolas.dichtel@6wind.com>

commit 85dfb745ee40232876663ae206cba35f24ab2a40 upstream.

This field was left uninitialized. Some user daemons perform check against this
field.

Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Cc: Luis Henriques <luis.henriques@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 net/key/af_key.c |    1 +
 1 file changed, 1 insertion(+)

--- a/net/key/af_key.c
+++ b/net/key/af_key.c
@@ -2687,6 +2687,7 @@ static int key_notify_policy_flush(const
 	hdr->sadb_msg_pid = c->pid;
 	hdr->sadb_msg_version = PF_KEY_V2;
 	hdr->sadb_msg_errno = (uint8_t) 0;
+	hdr->sadb_msg_satype = SADB_SATYPE_UNSPEC;
 	hdr->sadb_msg_len = (sizeof(struct sadb_msg) / sizeof(uint64_t));
 	hdr->sadb_msg_reserved = 0;
 	pfkey_broadcast(skb_out, GFP_ATOMIC, BROADCAST_ALL, NULL, c->net);

[ 23/34] iwl4965: set power mode early

[Greg Kroah-Hartman]

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

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

From: Stanislaw Gruszka <sgruszka@redhat.com>

commit eca396d7a5bdcc1fd67b1b12f737c213ac78a6f4 upstream.

If device was put into a sleep and system was restarted or module
reloaded, we have to wake device up before sending other commands.
Otherwise it will fail to start with Microcode error.

Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/net/wireless/iwlegacy/4965-mac.c |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

--- a/drivers/net/wireless/iwlegacy/4965-mac.c
+++ b/drivers/net/wireless/iwlegacy/4965-mac.c
@@ -5285,6 +5285,9 @@ il4965_alive_start(struct il_priv *il)
 
 	il->active_rate = RATES_MASK;
 
+	il_power_update_mode(il, true);
+	D_INFO("Updated power mode\n");
+
 	if (il_is_associated(il)) {
 		struct il_rxon_cmd *active_rxon =
 		    (struct il_rxon_cmd *)&il->active;
@@ -5315,9 +5318,6 @@ il4965_alive_start(struct il_priv *il)
 	D_INFO("ALIVE processing complete.\n");
 	wake_up(&il->wait_command_queue);
 
-	il_power_update_mode(il, true);
-	D_INFO("Updated power mode\n");
-
 	return;
 
 restart:

[ 24/34] iwl4965: reset firmware after rfkill off

[Greg Kroah-Hartman]

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

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

From: Stanislaw Gruszka <sgruszka@redhat.com>

commit 788f7a56fce1bcb2067b62b851a086fca48a0056 upstream.

Using rfkill switch can make firmware unstable, what cause various
Microcode errors and kernel warnings. Reseting firmware just after
rfkill off (radio on) helped with that.

Resolve:
https://bugzilla.redhat.com/show_bug.cgi?id=977053

Reported-and-tested-by: Justin Pearce <whitefox@guardianfox.net>
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/net/wireless/iwlegacy/4965-mac.c |   10 +++++-----
 drivers/net/wireless/iwlegacy/common.c   |    1 +
 2 files changed, 6 insertions(+), 5 deletions(-)

--- a/drivers/net/wireless/iwlegacy/4965-mac.c
+++ b/drivers/net/wireless/iwlegacy/4965-mac.c
@@ -4411,12 +4411,12 @@ il4965_irq_tasklet(struct il_priv *il)
 		 * is killed. Hence update the killswitch state here. The
 		 * rfkill handler will care about restarting if needed.
 		 */
-		if (!test_bit(S_ALIVE, &il->status)) {
-			if (hw_rf_kill)
-				set_bit(S_RFKILL, &il->status);
-			else
-				clear_bit(S_RFKILL, &il->status);
+		if (hw_rf_kill) {
+			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);
 		}
 
 		handled |= CSR_INT_BIT_RF_KILL;
--- a/drivers/net/wireless/iwlegacy/common.c
+++ b/drivers/net/wireless/iwlegacy/common.c
@@ -4659,6 +4659,7 @@ il_force_reset(struct il_priv *il, bool
 
 	return 0;
 }
+EXPORT_SYMBOL(il_force_reset);
 
 int
 il_mac_change_interface(struct ieee80211_hw *hw, struct ieee80211_vif *vif,

[ 25/34] can: pcan_usb: fix wrong memcpy() bytes length

[Greg Kroah-Hartman]

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

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

From: Stephane Grosjean <s.grosjean@peak-system.com>

commit 3c322a56b01695df15c70bfdc2d02e0ccd80654e upstream.

Fix possibly wrong memcpy() bytes length since some CAN records received from
PCAN-USB could define a DLC field in range [9..15].
In that case, the real DLC value MUST be used to move forward the record pointer
but, only 8 bytes max. MUST be copied into the data field of the struct
can_frame object of the skb given to the network core.

Signed-off-by: Stephane Grosjean <s.grosjean@peak-system.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/net/can/usb/peak_usb/pcan_usb.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/net/can/usb/peak_usb/pcan_usb.c
+++ b/drivers/net/can/usb/peak_usb/pcan_usb.c
@@ -649,7 +649,7 @@ static int pcan_usb_decode_data(struct p
 		if ((mc->ptr + rec_len) > mc->end)
 			goto decode_failed;
 
-		memcpy(cf->data, mc->ptr, rec_len);
+		memcpy(cf->data, mc->ptr, cf->can_dlc);
 		mc->ptr += rec_len;
 	}
 

[ 26/34] genetlink: fix family dump race

[Greg Kroah-Hartman]

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

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

From: Johannes Berg <johannes.berg@intel.com>

commit 58ad436fcf49810aa006016107f494c9ac9013db upstream.

When dumping generic netlink families, only the first dump call
is locked with genl_lock(), which protects the list of families,
and thus subsequent calls can access the data without locking,
racing against family addition/removal. This can cause a crash.
Fix it - the locking needs to be conditional because the first
time around it's already locked.

A similar bug was reported to me on an old kernel (3.4.47) but
the exact scenario that happened there is no longer possible,
on those kernels the first round wasn't locked either. Looking
at the current code I found the race described above, which had
also existed on the old kernel.

Reported-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 net/netlink/genetlink.c |    7 +++++++
 1 file changed, 7 insertions(+)

--- a/net/netlink/genetlink.c
+++ b/net/netlink/genetlink.c
@@ -744,6 +744,10 @@ static int ctrl_dumpfamily(struct sk_buf
 	struct net *net = sock_net(skb->sk);
 	int chains_to_skip = cb->args[0];
 	int fams_to_skip = cb->args[1];
+	bool need_locking = chains_to_skip || fams_to_skip;
+
+	if (need_locking)
+		genl_lock();
 
 	for (i = chains_to_skip; i < GENL_FAM_TAB_SIZE; i++) {
 		n = 0;
@@ -765,6 +769,9 @@ errout:
 	cb->args[0] = i;
 	cb->args[1] = n;
 
+	if (need_locking)
+		genl_unlock();
+
 	return skb->len;
 }
 

[ 27/34] usb: add two quirky touchscreen

[Greg Kroah-Hartman]

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

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

From: Oliver Neukum <oneukum@suse.de>

commit 304ab4ab079a8ed03ce39f1d274964a532db036b upstream.

These devices tend to become unresponsive after S3

Signed-off-by: Oliver Neukum <oneukum@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/usb/core/quirks.c |    6 ++++++
 1 file changed, 6 insertions(+)

--- a/drivers/usb/core/quirks.c
+++ b/drivers/usb/core/quirks.c
@@ -100,6 +100,12 @@ static const struct usb_device_id usb_qu
 	{ USB_DEVICE(0x04d8, 0x000c), .driver_info =
 			USB_QUIRK_CONFIG_INTF_STRINGS },
 
+	/* CarrolTouch 4000U */
+	{ USB_DEVICE(0x04e7, 0x0009), .driver_info = USB_QUIRK_RESET_RESUME },
+
+	/* CarrolTouch 4500U */
+	{ USB_DEVICE(0x04e7, 0x0030), .driver_info = USB_QUIRK_RESET_RESUME },
+
 	/* Samsung Android phone modem - ID conflict with SPH-I500 */
 	{ USB_DEVICE(0x04e8, 0x6601), .driver_info =
 			USB_QUIRK_CONFIG_INTF_STRINGS },

[ 28/34] USB: mos7720: fix broken control requests

[Greg Kroah-Hartman]

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

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

From: Johan Hovold <jhovold@gmail.com>

commit ef6c8c1d733e244f0499035be0dabe1f4ed98c6f upstream.

The parallel-port code of the drivers used a stack allocated
control-request buffer for asynchronous (and possibly deferred) control
requests. This not only violates the no-DMA-from-stack requirement but
could also lead to corrupt control requests being submitted.

Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/usb/serial/mos7720.c |   21 ++++++++++++++-------
 1 file changed, 14 insertions(+), 7 deletions(-)

--- a/drivers/usb/serial/mos7720.c
+++ b/drivers/usb/serial/mos7720.c
@@ -97,6 +97,7 @@ struct urbtracker {
 	struct list_head        urblist_entry;
 	struct kref             ref_count;
 	struct urb              *urb;
+	struct usb_ctrlrequest	*setup;
 };
 
 enum mos7715_pp_modes {
@@ -279,6 +280,7 @@ static void destroy_urbtracker(struct kr
 	struct mos7715_parport *mos_parport = urbtrack->mos_parport;
 	dbg("%s called", __func__);
 	usb_free_urb(urbtrack->urb);
+	kfree(urbtrack->setup);
 	kfree(urbtrack);
 	kref_put(&mos_parport->ref_count, destroy_mos_parport);
 }
@@ -363,7 +365,6 @@ static int write_parport_reg_nonblock(st
 	struct urbtracker *urbtrack;
 	int ret_val;
 	unsigned long flags;
-	struct usb_ctrlrequest setup;
 	struct usb_serial *serial = mos_parport->serial;
 	struct usb_device *usbdev = serial->dev;
 	dbg("%s called", __func__);
@@ -382,14 +383,20 @@ static int write_parport_reg_nonblock(st
 		kfree(urbtrack);
 		return -ENOMEM;
 	}
-	setup.bRequestType = (__u8)0x40;
-	setup.bRequest = (__u8)0x0e;
-	setup.wValue = get_reg_value(reg, dummy);
-	setup.wIndex = get_reg_index(reg);
-	setup.wLength = 0;
+	urbtrack->setup = kmalloc(sizeof(*urbtrack->setup), GFP_KERNEL);
+	if (!urbtrack->setup) {
+		usb_free_urb(urbtrack->urb);
+		kfree(urbtrack);
+		return -ENOMEM;
+	}
+	urbtrack->setup->bRequestType = (__u8)0x40;
+	urbtrack->setup->bRequest = (__u8)0x0e;
+	urbtrack->setup->wValue = get_reg_value(reg, dummy);
+	urbtrack->setup->wIndex = get_reg_index(reg);
+	urbtrack->setup->wLength = 0;
 	usb_fill_control_urb(urbtrack->urb, usbdev,
 			     usb_sndctrlpipe(usbdev, 0),
-			     (unsigned char *)&setup,
+			     (unsigned char *)urbtrack->setup,
 			     NULL, 0, async_complete, urbtrack);
 	kref_init(&urbtrack->ref_count);
 	INIT_LIST_HEAD(&urbtrack->urblist_entry);

[ 29/34] xtensa: fix linker script transformation for .text.unlikely

[Greg Kroah-Hartman]

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

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

From: Max Filippov <jcmvbkbc@gmail.com>

commit f6a03a12ecdbe0dd80a55f6df3b7206c5a403a49 upstream.

Now that binutils generate *.unlikely sections which don't follow
documented (info as) literal section naming rules, section name
transformation script doesn't work well resulting in the following
errors at vmlinux link time:

	main.c:(.text.unlikely+0x3): dangerous relocation: l32r: literal
				     placed after use: .literal.unlikely

Fix section name transformation script by adding specific rule for
.text.unlikely sections.

Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: Chris Zankel <chris@zankel.net>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 arch/xtensa/kernel/Makefile |    1 +
 1 file changed, 1 insertion(+)

--- a/arch/xtensa/kernel/Makefile
+++ b/arch/xtensa/kernel/Makefile
@@ -24,6 +24,7 @@ obj-$(CONFIG_MODULES) += xtensa_ksyms.o
 # Replicate rules in scripts/Makefile.build
 
 sed-y = -e 's/\*(\(\.[a-z]*it\|\.ref\|\)\.text)/*(\1.literal \1.text)/g'    \
+	-e 's/\.text\.unlikely/.literal.unlikely .text.unlikely/g' \
 	-e 's/\*(\(\.text\.[a-z]*\))/*(\1.literal \1)/g'
 
 quiet_cmd__cpp_lds_S = LDS     $@

[ 30/34] xtensa: replace xtensa-specific _f{data,text} by _s{data,text}

[Greg Kroah-Hartman]

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

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

From: Geert Uytterhoeven <geert@linux-m68k.org>

commit 5e7b6ed8e9bf3c8e3bb579fd0aec64f6526f8c81 upstream.

commit a2d063ac216c161 ("extable, core_kernel_data(): Make sure all archs
define _sdata") missed xtensa.  Xtensa does have a start of data marker,
but calls it _fdata, causing

    kernel/built-in.o:(.text+0x964): undefined reference to `_sdata'

_stext was already defined, but it was duplicated by _fdata.

Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Chris Zankel <chris@zankel.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 arch/xtensa/kernel/vmlinux.lds.S |    3 +--
 arch/xtensa/mm/init.c            |    6 +++---
 2 files changed, 4 insertions(+), 5 deletions(-)

--- a/arch/xtensa/kernel/vmlinux.lds.S
+++ b/arch/xtensa/kernel/vmlinux.lds.S
@@ -83,7 +83,6 @@ SECTIONS
 
   _text = .;
   _stext = .;
-  _ftext = .;
 
   .text :
   {
@@ -112,7 +111,7 @@ SECTIONS
   EXCEPTION_TABLE(16)
   /* Data section */
 
-  _fdata = .;
+  _sdata = .;
   RW_DATA_SECTION(XCHAL_ICACHE_LINESIZE, PAGE_SIZE, THREAD_SIZE)
   _edata = .;
 
--- a/arch/xtensa/mm/init.c
+++ b/arch/xtensa/mm/init.c
@@ -29,7 +29,7 @@
 
 /* References to section boundaries */
 
-extern char _ftext, _etext, _fdata, _edata, _rodata_end;
+extern char _stext, _etext, _sdata, _edata, _rodata_end;
 extern char __init_begin, __init_end;
 
 /*
@@ -197,8 +197,8 @@ void __init mem_init(void)
 			reservedpages++;
 	}
 
-	codesize =  (unsigned long) &_etext - (unsigned long) &_ftext;
-	datasize =  (unsigned long) &_edata - (unsigned long) &_fdata;
+	codesize =  (unsigned long) &_etext - (unsigned long) &_stext;
+	datasize =  (unsigned long) &_edata - (unsigned long) &_sdata;
 	initsize =  (unsigned long) &__init_end - (unsigned long) &__init_begin;
 
 	printk("Memory: %luk/%luk available (%ldk kernel code, %ldk reserved, "

[ 31/34] ARM: 7809/1: perf: fix event validation for software group leaders

[Greg Kroah-Hartman]

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

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

From: Will Deacon <will.deacon@arm.com>

commit c95eb3184ea1a3a2551df57190c81da695e2144b upstream.

It is possible to construct an event group with a software event as a
group leader and then subsequently add a hardware event to the group.
This results in the event group being validated by adding all members
of the group to a fake PMU and attempting to allocate each event on
their respective PMU.

Unfortunately, for software events wthout a corresponding arm_pmu, this
results in a kernel crash attempting to dereference the ->get_event_idx
function pointer.

This patch fixes the problem by checking explicitly for software events
and ignoring those in event validation (since they can always be
scheduled). We will probably want to revisit this for 3.12, since the
validation checks don't appear to work correctly when dealing with
multiple hardware PMUs anyway.

Reported-by: Vince Weaver <vincent.weaver@maine.edu>
Tested-by: Vince Weaver <vincent.weaver@maine.edu>
Tested-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 arch/arm/kernel/perf_event.c |    3 +++
 1 file changed, 3 insertions(+)

--- a/arch/arm/kernel/perf_event.c
+++ b/arch/arm/kernel/perf_event.c
@@ -324,6 +324,9 @@ validate_event(struct pmu_hw_events *hw_
 	struct hw_perf_event fake_event = event->hw;
 	struct pmu *leader_pmu = event->group_leader->pmu;
 
+	if (is_software_event(event))
+		return 1;
+
 	if (event->pmu != leader_pmu || event->state < PERF_EVENT_STATE_OFF)
 		return 1;
 

[ 32/34] m68k: Truncate base in do_div()

[Greg Kroah-Hartman]

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

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

From: Andreas Schwab <schwab@linux-m68k.org>

commit ea077b1b96e073eac5c3c5590529e964767fc5f7 upstream.

Explicitly truncate the second operand of do_div() to 32 bits to guard
against bogus code calling it with a 64-bit divisor.

[Thorsten]

After upgrading from 3.2 to 3.10, mounting a btrfs volume fails with:

btrfs: setting nodatacow, compression disabled
btrfs: enabling auto recovery
btrfs: disk space caching is enabled
---
 arch/m68k/include/asm/div64.h |    9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

--- a/arch/m68k/include/asm/div64.h
+++ b/arch/m68k/include/asm/div64.h
@@ -15,16 +15,17 @@
 		unsigned long long n64;				\
 	} __n;							\
 	unsigned long __rem, __upper;				\
+	unsigned long __base = (base);				\
 								\
 	__n.n64 = (n);						\
 	if ((__upper = __n.n32[0])) {				\
 		asm ("divul.l %2,%1:%0"				\
-			: "=d" (__n.n32[0]), "=d" (__upper)	\
-			: "d" (base), "0" (__n.n32[0]));	\
+		     : "=d" (__n.n32[0]), "=d" (__upper)	\
+		     : "d" (__base), "0" (__n.n32[0]));		\
 	}							\
 	asm ("divu.l %2,%1:%0"					\
-		: "=d" (__n.n32[1]), "=d" (__rem)		\
-		: "d" (base), "1" (__upper), "0" (__n.n32[1]));	\
+	     : "=d" (__n.n32[1]), "=d" (__rem)			\
+	     : "d" (__base), "1" (__upper), "0" (__n.n32[1]));	\
 	(n) = __n.n64;						\
 	__rem;							\
 })

[ 33/34] m68k/atari: ARAnyM - Fix NatFeat module support

[Greg Kroah-Hartman]

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

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

From: Geert Uytterhoeven <geert@linux-m68k.org>

commit e8184e10f89736a23ea6eea8e24cd524c5c513d2 upstream.

As pointed out by Andreas Schwab, pointers passed to ARAnyM NatFeat calls
should be physical addresses, not virtual addresses.

Fortunately on Atari, physical and virtual kernel addresses are the same,
as long as normal kernel memory is concerned, so this usually worked fine
without conversion.

But for modules, pointers to literal strings are located in vmalloc()ed
memory. Depending on the version of ARAnyM, this causes the nf_get_id()
call to just fail, or worse, crash ARAnyM itself with e.g.

    Gotcha! Illegal memory access. Atari PC = $968c

This is a big issue for distro kernels, who want to have all drivers as
loadable modules in an initrd.

Add a wrapper for nf_get_id() that copies the literal to the stack to
work around this issue.

Reported-by: Thorsten Glaser <tg@debian.org>
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 arch/m68k/emu/natfeat.c |   23 +++++++++++++++++++----
 1 file changed, 19 insertions(+), 4 deletions(-)

--- a/arch/m68k/emu/natfeat.c
+++ b/arch/m68k/emu/natfeat.c
@@ -18,9 +18,11 @@
 #include <asm/machdep.h>
 #include <asm/natfeat.h>
 
+extern long nf_get_id2(const char *feature_name);
+
 asm("\n"
-"	.global nf_get_id,nf_call\n"
-"nf_get_id:\n"
+"	.global nf_get_id2,nf_call\n"
+"nf_get_id2:\n"
 "	.short	0x7300\n"
 "	rts\n"
 "nf_call:\n"
@@ -29,12 +31,25 @@ asm("\n"
 "1:	moveq.l	#0,%d0\n"
 "	rts\n"
 "	.section __ex_table,\"a\"\n"
-"	.long	nf_get_id,1b\n"
+"	.long	nf_get_id2,1b\n"
 "	.long	nf_call,1b\n"
 "	.previous");
-EXPORT_SYMBOL_GPL(nf_get_id);
 EXPORT_SYMBOL_GPL(nf_call);
 
+long nf_get_id(const char *feature_name)
+{
+	/* feature_name may be in vmalloc()ed memory, so make a copy */
+	char name_copy[32];
+	size_t n;
+
+	n = strlcpy(name_copy, feature_name, sizeof(name_copy));
+	if (n >= sizeof(name_copy))
+		return 0;
+
+	return nf_get_id2(name_copy);
+}
+EXPORT_SYMBOL_GPL(nf_get_id);
+
 void nfprint(const char *fmt, ...)
 {
 	static char buf[256];

[ 34/34] jbd2: Fix use after free after error in jbd2_journal_dirty_metadata()

[Greg Kroah-Hartman]

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

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

From: Jan Kara <jack@suse.cz>

commit 91aa11fae1cf8c2fd67be0609692ea9741cdcc43 upstream.

When jbd2_journal_dirty_metadata() returns error,
__ext4_handle_dirty_metadata() stops the handle. However callers of this
function do not count with that fact and still happily used now freed
handle. This use after free can result in various issues but very likely
we oops soon.

The motivation of adding __ext4_journal_stop() into
__ext4_handle_dirty_metadata() in commit 9ea7a0df seems to be only to
improve error reporting. So replace __ext4_journal_stop() with
ext4_journal_abort_handle() which was there before that commit and add
WARN_ON_ONCE() to dump stack to provide useful information.

Reported-by: Sage Weil <sage@inktank.com>
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 fs/ext4/ext4_jbd2.c |    8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

--- a/fs/ext4/ext4_jbd2.c
+++ b/fs/ext4/ext4_jbd2.c
@@ -109,10 +109,10 @@ int __ext4_handle_dirty_metadata(const c
 
 	if (ext4_handle_valid(handle)) {
 		err = jbd2_journal_dirty_metadata(handle, bh);
-		if (err) {
-			/* Errors can only happen if there is a bug */
-			handle->h_err = err;
-			__ext4_journal_stop(where, line, handle);
+		/* Errors can only happen if there is a bug */
+		if (WARN_ON_ONCE(err)) {
+			ext4_journal_abort_handle(where, line, __func__, bh,
+						  handle, err);
 		}
 	} else {
 		if (inode)

Re: [ 00/34] 3.4.59-stable review

[Guenter Roeck]

On 08/18/2013 01:34 PM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.4.59 release.
> There are 34 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.
>
> Note, there are a number of "build fixes" in this round, in the quest to
> get all arches building properly to be able to track future regressions
> easier.  Many thanks to Guenter Roeck and Geert Uytterhoeven for their
> work in doing this.
>
> Responses should be made by Tue Aug 20 20:32:48 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.4.59-rc1.gz
> and the diffstat can be found below.
>

Build results:
	Total builds: 69 Total build errors: 2
Previous release:
	Total builds: 62 Total build errors: 10

qemu:
	mips, mips64, ppc, x86, x86_64: pass (boot to login prompt)
	arm: skipped

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

More builds, significantly fewer failures, so results are excellent.

Still failing builds are arm:allmodconfig and sparc64:allmodconfig.
Both may be difficult to fix.

Thanks,
Guenter

Re: [ 00/34] 3.4.59-stable review

[Shuah Khan]

On 08/18/2013 02:34 PM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.4.59 release.
> There are 34 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.
>
> Note, there are a number of "build fixes" in this round, in the quest to
> get all arches building properly to be able to track future regressions
> easier.  Many thanks to Guenter Roeck and Geert Uytterhoeven for their
> work in doing this.
>
> Responses should be made by Tue Aug 20 20:32:48 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.4.59-rc1.gz
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>

Greg,

This release is not looking good on one of test systems. Bluetooth is 
not recognized and wireless doesn't work. I am going to start bisect and 
giving you a head-up. The following new dmesg -l crit regression messages:

CPU2: Package power limit notification (total events = 1)
CPU3: Package power limit notification (total events = 1)
CPU0: Package power limit notification (total events = 1)
CPU1: Package power limit notification (total events = 1)

and the following traces in dmesg:
[  124.802169] init: udevtrigger post-stop process (353) terminated with 
status 1
[  243.439212] INFO: task crda:723 blocked for more than 120 seconds.
[  243.439220] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" 
disables this message.
[  243.439227] crda            D ffff88041f253940     0   723    362 
0x00000004
[  243.439237]  ffff8803fbde59d8 0000000000000082 ffff880404a4dbc0 
ffff8803fbde5fd8
[  243.439248]  ffff8803fbde5fd8 ffff8803fbde5fd8 ffff8803eca2c4d0 
ffff880404a4dbc0
[  243.439257]  ffff880404a4dbc0 ffffffff81caa2a0 ffff880404a4dbc0 
ffffffff81caa2a4
[  243.439266] Call Trace:
[  243.439283]  [<ffffffff816681f9>] schedule+0x29/0x70
[  243.439292]  [<ffffffff816684be>] schedule_preempt_disabled+0xe/0x10
[  243.439301]  [<ffffffff81666fa7>] __mutex_lock_slowpath+0xd7/0x150
[  243.439312]  [<ffffffff8158498e>] ? genl_rcv_msg+0x16e/0x2d0
[  243.439321]  [<ffffffff81666a7a>] mutex_lock+0x2a/0x50
[  243.439328]  [<ffffffff815847d5>] genl_lock+0x15/0x20
[  243.439335]  [<ffffffff815855fc>] ctrl_dumpfamily+0x12c/0x140
[  243.439343]  [<ffffffff81581c53>] netlink_dump+0x73/0x1e0
[  243.439350]  [<ffffffff815821d8>] netlink_recvmsg+0x338/0x430
[  243.439358]  [<ffffffff8154555d>] sock_recvmsg+0xfd/0x130
[  243.439371]  [<ffffffff81172a93>] ? __mem_cgroup_commit_charge+0xb3/0x2f0
[  243.439382]  [<ffffffff8114a78d>] ? page_add_new_anon_rmap+0xcd/0xf0
[  243.439389]  [<ffffffff8154692a>] ? move_addr_to_kernel+0x5a/0xc0
[  243.439399]  [<ffffffff815521a6>] ? verify_iovec+0x56/0xd0
[  243.439406]  [<ffffffff81545073>] ___sys_recvmsg+0x143/0x2d0
[  243.439414]  [<ffffffff81141349>] ? handle_mm_fault+0x259/0x320
[  243.439424]  [<ffffffff8154420c>] ? move_addr_to_user+0xbc/0xe0
[  243.439431]  [<ffffffff8154715c>] ? sys_getsockname+0xdc/0xf0
[  243.439437]  [<ffffffff81547ae9>] __sys_recvmsg+0x49/0x90
[  243.439444]  [<ffffffff81547b42>] sys_recvmsg+0x12/0x30
[  243.439455]  [<ffffffff816712e9>] system_call_fastpath+0x16/0x1b
[  243.439463] INFO: task NetworkManager:879 blocked for more than 120 
seconds.
[  243.439468] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" 
disables this message.
[  243.439473] NetworkManager  D ffff88041f293940     0   879      1 
0x00000000
[  243.439481]  ffff8804065c1a08 0000000000000082 ffff8803ecbedbc0 
ffff8804065c1fd8
[  243.439490]  ffff8804065c1fd8 ffff8804065c1fd8 ffff880408d796f0 
ffff8803ecbedbc0
[  243.439498]  ffff8804065c1ab8 ffffffff81caa2a0 ffff8803ecbedbc0 
ffffffff81caa2a4
[  243.439506] Call Trace:
[  243.439514]  [<ffffffff816681f9>] schedule+0x29/0x70
[  243.439522]  [<ffffffff816684be>] schedule_preempt_disabled+0xe/0x10
[  243.439530]  [<ffffffff81666fa7>] __mutex_lock_slowpath+0xd7/0x150
[  243.439539]  [<ffffffff81666a7a>] mutex_lock+0x2a/0x50
[  243.439546]  [<ffffffff815847d5>] genl_lock+0x15/0x20
[  243.439553]  [<ffffffff815847f6>] genl_rcv+0x16/0x40
[  243.439560]  [<ffffffff81583d1d>] netlink_unicast+0x19d/0x1f0
[  243.439567]  [<ffffffff8158404a>] netlink_sendmsg+0x2da/0x390
[  243.439574]  [<ffffffff815456e8>] sock_sendmsg+0xf8/0x130
[  243.439582]  [<ffffffff8154692a>] ? move_addr_to_kernel+0x5a/0xc0
[  243.439590]  [<ffffffff815521a6>] ? verify_iovec+0x56/0xd0
[  243.439597]  [<ffffffff81545b9e>] ___sys_sendmsg+0x41e/0x430
[  243.439607]  [<ffffffff8107e733>] ? __wake_up+0x53/0x70
[  243.439614]  [<ffffffff81582b43>] ? netlink_table_ungrab+0x33/0x40
[  243.439623]  [<ffffffff8154420c>] ? move_addr_to_user+0xbc/0xe0
[  243.439629]  [<ffffffff81547115>] ? sys_getsockname+0x95/0xf0
[  243.439636]  [<ffffffff81547869>] __sys_sendmsg+0x49/0x90
[  243.439643]  [<ffffffff815478c2>] sys_sendmsg+0x12/0x30
[  243.439651]  [<ffffffff816712e9>] system_call_fastpath+0x16/0x1b
[  363.295849] INFO: task crda:723 blocked for more than 120 seconds.
[  363.295858] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" 
disables this message.


-- Shuah

Shuah Khan
Senior Linux Kernel Developer - Open Source Group
Samsung Research America(Silicon Valley)
shuah.kh@samsung.com | (970) 672-0658

Re: [ 00/34] 3.4.59-stable review

[Greg Kroah-Hartman]

On Mon, Aug 19, 2013 at 12:02:17PM -0600, Shuah Khan wrote:
> On 08/18/2013 02:34 PM, Greg Kroah-Hartman wrote:
> >This is the start of the stable review cycle for the 3.4.59 release.
> >There are 34 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.
> >
> >Note, there are a number of "build fixes" in this round, in the quest to
> >get all arches building properly to be able to track future regressions
> >easier.  Many thanks to Guenter Roeck and Geert Uytterhoeven for their
> >work in doing this.
> >
> >Responses should be made by Tue Aug 20 20:32:48 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.4.59-rc1.gz
> >and the diffstat can be found below.
> >
> >thanks,
> >
> >greg k-h
> >
> 
> Greg,
> 
> This release is not looking good on one of test systems. Bluetooth
> is not recognized and wireless doesn't work. I am going to start
> bisect and giving you a head-up. The following new dmesg -l crit
> regression messages:

That's odd, given that there are no bluetooth changes in this release.

> CPU2: Package power limit notification (total events = 1)
> CPU3: Package power limit notification (total events = 1)
> CPU0: Package power limit notification (total events = 1)
> CPU1: Package power limit notification (total events = 1)
> 
> and the following traces in dmesg:
> [  124.802169] init: udevtrigger post-stop process (353) terminated
> with status 1
> [  243.439212] INFO: task crda:723 blocked for more than 120 seconds.

What is "crda"?

Any luck with bisection?  It should go fast as the majority of patches
here are non-x86.

thanks,

greg k-h

Re: [ 00/34] 3.4.59-stable review

[Stefan Lippers-Hollmann]

Hi

On Monday 19 August 2013, Greg Kroah-Hartman wrote:
> On Mon, Aug 19, 2013 at 12:02:17PM -0600, Shuah Khan wrote:
> > On 08/18/2013 02:34 PM, Greg Kroah-Hartman wrote:
[…] 
> > and the following traces in dmesg:
> > [  124.802169] init: udevtrigger post-stop process (353) terminated
> > with status 1
> > [  243.439212] INFO: task crda:723 blocked for more than 120 seconds.
> 
> What is "crda"?
> 
> Any luck with bisection?  It should go fast as the majority of patches
> here are non-x86.

crda is a userspace helper, invoked by udev events, which sets -and
intersects as needed- the regulatory domain settings for (modern, 
cfg80211 based) wlan hardware based on the device's EEPROM regdom hint,
local configuration (country code) and eventual IEEE 802.11d hints 
(country IEs) beaconed by access points nearby. It hooks into udev with
these udev rules (Debian/ 1.1.2-1):

$ grep -v -e ^$ -e ^\# /lib/udev/rules.d/60-crda.rules 
SUBSYSTEM=="ieee80211", ACTION=="add", RUN+="/lib/crda/setregdomain"

$ grep -v -e ^$ -e ^\# /lib/udev/rules.d/85-regulatory.rules 
KERNEL=="regulatory*", ACTION=="change", SUBSYSTEM=="platform", RUN+="/sbin/crda"

Full source is at [2], it should be installed on pretty much every 
distro/ system released with wlan support for the last >>3 years.

There are two iwl4965 patches in this series, which might be among the
first ones to check - /if/ you actually have that hardware, the second
one (iwl4965: reset firmware after rfkill off) might also indirectly 
have an effect on blutetooth (via rfkill).

Regards
	Stefan Lippers-Hollmann

[1]	http://wireless.kernel.org/en/developers/Regulatory/CRDA
[2]	https://github.com/mcgrof/crda

Re: [ 00/34] 3.4.59-stable review

[Shuah Khan]

On 08/19/2013 02:14 PM, Stefan Lippers-Hollmann wrote:
> Hi
>
> On Monday 19 August 2013, Greg Kroah-Hartman wrote:
>> On Mon, Aug 19, 2013 at 12:02:17PM -0600, Shuah Khan wrote:
>>> On 08/18/2013 02:34 PM, Greg Kroah-Hartman wrote:
> […]
>>> and the following traces in dmesg:
>>> [  124.802169] init: udevtrigger post-stop process (353) terminated
>>> with status 1
>>> [  243.439212] INFO: task crda:723 blocked for more than 120 seconds.
>>
>> What is "crda"?
>>
>> Any luck with bisection?  It should go fast as the majority of patches
>> here are non-x86.
>
> crda is a userspace helper, invoked by udev events, which sets -and
> intersects as needed- the regulatory domain settings for (modern,
> cfg80211 based) wlan hardware based on the device's EEPROM regdom hint,
> local configuration (country code) and eventual IEEE 802.11d hints
> (country IEs) beaconed by access points nearby. It hooks into udev with
> these udev rules (Debian/ 1.1.2-1):
>
> $ grep -v -e ^$ -e ^\# /lib/udev/rules.d/60-crda.rules
> SUBSYSTEM=="ieee80211", ACTION=="add", RUN+="/lib/crda/setregdomain"
>
> $ grep -v -e ^$ -e ^\# /lib/udev/rules.d/85-regulatory.rules
> KERNEL=="regulatory*", ACTION=="change", SUBSYSTEM=="platform", RUN+="/sbin/crda"
>
> Full source is at [2], it should be installed on pretty much every
> distro/ system released with wlan support for the last >>3 years.
>
> There are two iwl4965 patches in this series, which might be among the
> first ones to check - /if/ you actually have that hardware, the second
> one (iwl4965: reset firmware after rfkill off) might also indirectly
> have an effect on blutetooth (via rfkill).
>
> Regards
> 	Stefan Lippers-Hollmann
>
> [1]	http://wireless.kernel.org/en/developers/Regulatory/CRDA
> [2]	https://github.com/mcgrof/crda
>

Greg,

git bisect shows the following patch as the problem:

[ 26/34] genetlink: fix family dump race


-- Shuah

-- 
Shuah Khan
Senior Linux Kernel Developer - Open Source Group
Samsung Research America(Silicon Valley)
shuah.kh@samsung.com | (970) 672-0658

Re: [ 00/34] 3.4.59-stable review

[Greg Kroah-Hartman]

On Mon, Aug 19, 2013 at 04:22:59PM -0600, Shuah Khan wrote:
> On 08/19/2013 02:14 PM, Stefan Lippers-Hollmann wrote:
> >Hi
> >
> >On Monday 19 August 2013, Greg Kroah-Hartman wrote:
> >>On Mon, Aug 19, 2013 at 12:02:17PM -0600, Shuah Khan wrote:
> >>>On 08/18/2013 02:34 PM, Greg Kroah-Hartman wrote:
> >[…]
> >>>and the following traces in dmesg:
> >>>[  124.802169] init: udevtrigger post-stop process (353) terminated
> >>>with status 1
> >>>[  243.439212] INFO: task crda:723 blocked for more than 120 seconds.
> >>
> >>What is "crda"?
> >>
> >>Any luck with bisection?  It should go fast as the majority of patches
> >>here are non-x86.
> >
> >crda is a userspace helper, invoked by udev events, which sets -and
> >intersects as needed- the regulatory domain settings for (modern,
> >cfg80211 based) wlan hardware based on the device's EEPROM regdom hint,
> >local configuration (country code) and eventual IEEE 802.11d hints
> >(country IEs) beaconed by access points nearby. It hooks into udev with
> >these udev rules (Debian/ 1.1.2-1):
> >
> >$ grep -v -e ^$ -e ^\# /lib/udev/rules.d/60-crda.rules
> >SUBSYSTEM=="ieee80211", ACTION=="add", RUN+="/lib/crda/setregdomain"
> >
> >$ grep -v -e ^$ -e ^\# /lib/udev/rules.d/85-regulatory.rules
> >KERNEL=="regulatory*", ACTION=="change", SUBSYSTEM=="platform", RUN+="/sbin/crda"
> >
> >Full source is at [2], it should be installed on pretty much every
> >distro/ system released with wlan support for the last >>3 years.
> >
> >There are two iwl4965 patches in this series, which might be among the
> >first ones to check - /if/ you actually have that hardware, the second
> >one (iwl4965: reset firmware after rfkill off) might also indirectly
> >have an effect on blutetooth (via rfkill).
> >
> >Regards
> >	Stefan Lippers-Hollmann
> >
> >[1]	http://wireless.kernel.org/en/developers/Regulatory/CRDA
> >[2]	https://github.com/mcgrof/crda
> >
> 
> Greg,
> 
> git bisect shows the following patch as the problem:
> 
> [ 26/34] genetlink: fix family dump race

Johannes, another strike against this patch :(

Any chance on fixing it upstream and me sucking that fix in?

thanks,

greg k-h

Re: [ 00/34] 3.4.59-stable review

[Shuah Khan]

On 08/19/2013 04:22 PM, Shuah Khan wrote:
> On 08/19/2013 02:14 PM, Stefan Lippers-Hollmann wrote:
>> Hi
>>
>> On Monday 19 August 2013, Greg Kroah-Hartman wrote:
>>> On Mon, Aug 19, 2013 at 12:02:17PM -0600, Shuah Khan wrote:
>>>> On 08/18/2013 02:34 PM, Greg Kroah-Hartman wrote:
>> […]
>>>> and the following traces in dmesg:
>>>> [  124.802169] init: udevtrigger post-stop process (353) terminated
>>>> with status 1
>>>> [  243.439212] INFO: task crda:723 blocked for more than 120 seconds.
>>>
>>> What is "crda"?
>>>
>>> Any luck with bisection?  It should go fast as the majority of patches
>>> here are non-x86.
>>
>> crda is a userspace helper, invoked by udev events, which sets -and
>> intersects as needed- the regulatory domain settings for (modern,
>> cfg80211 based) wlan hardware based on the device's EEPROM regdom hint,
>> local configuration (country code) and eventual IEEE 802.11d hints
>> (country IEs) beaconed by access points nearby. It hooks into udev with
>> these udev rules (Debian/ 1.1.2-1):
>>
>> $ grep -v -e ^$ -e ^\# /lib/udev/rules.d/60-crda.rules
>> SUBSYSTEM=="ieee80211", ACTION=="add", RUN+="/lib/crda/setregdomain"
>>
>> $ grep -v -e ^$ -e ^\# /lib/udev/rules.d/85-regulatory.rules
>> KERNEL=="regulatory*", ACTION=="change", SUBSYSTEM=="platform",
>> RUN+="/sbin/crda"
>>
>> Full source is at [2], it should be installed on pretty much every
>> distro/ system released with wlan support for the last >>3 years.
>>
>> There are two iwl4965 patches in this series, which might be among the
>> first ones to check - /if/ you actually have that hardware, the second
>> one (iwl4965: reset firmware after rfkill off) might also indirectly
>> have an effect on blutetooth (via rfkill).
>>
>> Regards
>>     Stefan Lippers-Hollmann
>>
>> [1]    http://wireless.kernel.org/en/developers/Regulatory/CRDA
>> [2]    https://github.com/mcgrof/crda
>>
>
> Greg,
>
> git bisect shows the following patch as the problem:
>
> [ 26/34] genetlink: fix family dump race
>
>
> -- Shuah
>

Interesting. The same patch is in 3.10.8 as well, and I don't see this 
problem on this system on 3.10.8.

-- Shuah

-- 
Shuah Khan
Senior Linux Kernel Developer - Open Source Group
Samsung Research America(Silicon Valley)
shuah.kh@samsung.com | (970) 672-0658

RE: [ 00/34] 3.4.59-stable review

[Berg, Johannes]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 909 bytes --]

> > [ 26/34] genetlink: fix family dump race
> 
> Johannes, another strike against this patch :(
> 
> Any chance on fixing it upstream and me sucking that fix in?

Yeah, I'm trying to get that, but it's not clear to me how to fix it. Where did you apply it? It was going to need some fixes but when the first objection was raised I figured you were going to drop it for now completely? Sorry for the mess :-(

johannes
-- 

Intel GmbH
Dornacher Strasse 1
85622 Feldkirchen/Muenchen, Deutschland
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk
Registergericht: Muenchen HRB 47456
Ust.-IdNr./VAT Registration No.: DE129385895
Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052
ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

Re: [ 00/34] 3.4.59-stable review

[Greg Kroah-Hartman]

On Tue, Aug 20, 2013 at 07:36:00AM +0000, Berg, Johannes wrote:
> > > [ 26/34] genetlink: fix family dump race
> > 
> > Johannes, another strike against this patch :(
> > 
> > Any chance on fixing it upstream and me sucking that fix in?
> 
> Yeah, I'm trying to get that, but it's not clear to me how to fix it.
> Where did you apply it? It was going to need some fixes but when the
> first objection was raised I figured you were going to drop it for now
> completely? Sorry for the mess :-(

You're right, I'll drop this for 3.4, it doesn't make sense there.

thanks,

greg k-h

RE: [ 00/34] 3.4.59-stable review

[Berg, Johannes]

> > Yeah, I'm trying to get that, but it's not clear to me how to fix it.
> > Where did you apply it? It was going to need some fixes but when the
> > first objection was raised I figured you were going to drop it for now
> > completely? Sorry for the mess :-(
> 
> You're right, I'll drop this for 3.4, it doesn't make sense there.

Technically, the bug does exist on 3.4 (it was actually reported to me there :) ) but the fix would have to be significantly different, there's very different locking for dump in generic netlink there. Given that I can't even seem to figure out the current version, it's probably best to not worry about 3.4 ...

johannes
-- 

Intel GmbH
Dornacher Strasse 1
85622 Feldkirchen/Muenchen, Deutschland
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk
Registergericht: Muenchen HRB 47456
Ust.-IdNr./VAT Registration No.: DE129385895
Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052

Re: [ 00/34] 3.4.59-stable review

[Hugh Dickins]

On Tue, 20 Aug 2013, Greg Kroah-Hartman wrote:
> On Tue, Aug 20, 2013 at 07:36:00AM +0000, Berg, Johannes wrote:
> > > > [ 26/34] genetlink: fix family dump race
> > > 
> > > Johannes, another strike against this patch :(
> > > 
> > > Any chance on fixing it upstream and me sucking that fix in?
> > 
> > Yeah, I'm trying to get that, but it's not clear to me how to fix it.
> > Where did you apply it? It was going to need some fixes but when the
> > first objection was raised I figured you were going to drop it for now
> > completely? Sorry for the mess :-(
> 
> You're right, I'll drop this for 3.4, it doesn't make sense there.

And you'll drop it from 3.0 and 3.10 also, I hope?

Thanks,
Hugh

Re: [ 00/34] 3.4.59-stable review

[Greg Kroah-Hartman]

On Tue, Aug 20, 2013 at 08:53:24AM -0700, Hugh Dickins wrote:
> On Tue, 20 Aug 2013, Greg Kroah-Hartman wrote:
> > On Tue, Aug 20, 2013 at 07:36:00AM +0000, Berg, Johannes wrote:
> > > > > [ 26/34] genetlink: fix family dump race
> > > > 
> > > > Johannes, another strike against this patch :(
> > > > 
> > > > Any chance on fixing it upstream and me sucking that fix in?
> > > 
> > > Yeah, I'm trying to get that, but it's not clear to me how to fix it.
> > > Where did you apply it? It was going to need some fixes but when the
> > > first objection was raised I figured you were going to drop it for now
> > > completely? Sorry for the mess :-(
> > 
> > You're right, I'll drop this for 3.4, it doesn't make sense there.
> 
> And you'll drop it from 3.0 and 3.10 also, I hope?

It wasn't in 3.0, was it?  Oh crap, it was...

3.10, I'd rather have the "real" fix that ends up resolving the issue in
Linus's tree also, instead of just dropping it.

Especially as I just did the releases...

thanks,

greg k-h

Re: [ 00/34] 3.4.59-stable review

[Hugh Dickins]

On Tue, 20 Aug 2013, Greg Kroah-Hartman wrote:
> On Tue, Aug 20, 2013 at 08:53:24AM -0700, Hugh Dickins wrote:
> > On Tue, 20 Aug 2013, Greg Kroah-Hartman wrote:
> > > On Tue, Aug 20, 2013 at 07:36:00AM +0000, Berg, Johannes wrote:
> > > > > > [ 26/34] genetlink: fix family dump race
> > > > > 
> > > > > Johannes, another strike against this patch :(
> > > > > 
> > > > > Any chance on fixing it upstream and me sucking that fix in?
> > > > 
> > > > Yeah, I'm trying to get that, but it's not clear to me how to fix it.
> > > > Where did you apply it? It was going to need some fixes but when the
> > > > first objection was raised I figured you were going to drop it for now
> > > > completely? Sorry for the mess :-(
> > > 
> > > You're right, I'll drop this for 3.4, it doesn't make sense there.
> > 
> > And you'll drop it from 3.0 and 3.10 also, I hope?
> 
> It wasn't in 3.0, was it?  Oh crap, it was...
> 
> 3.10, I'd rather have the "real" fix that ends up resolving the issue in
> Linus's tree also, instead of just dropping it.

We would all prefer that, but as yet the real fix is unknown,
and lockdep shows problems with the real fix (please search your
mailbox for "3.11-rc6 genetlink locking fix offends lockdep").

> 
> Especially as I just did the releases...

Oh.  Classic case of a patch rushed too quickly into late rc,
then too quickly from there to stable.

Hugh

Re: [ 00/34] 3.4.59-stable review

[Steven Rostedt]

On Tue, 20 Aug 2013 09:25:05 -0700 (PDT)
Hugh Dickins <hughd@google.com> wrote:

 
> > 
> > Especially as I just did the releases...
> 
> Oh.  Classic case of a patch rushed too quickly into late rc,
> then too quickly from there to stable.
> 

I think we should focus more on having a correct fix than a quick fix
and rush it into mainline. I was criticized for pushing a rather
complex fix into -rc4, and was told that I should wait to 3.12. The
thing is, we had various versions of a fix by -rc1, but I wasn't
satisfied with it. After several rounds we were finally happy with the
fix and by that time, -rc4 was out. I pushed it regardless, as why
should I wait to 3.12 and then push it to stable? We all took our time,
tested the hell out of it (although not as much as it would get going
mainline), had it in linux-next for several days, knew the bug inside
and out and then when we were happy, added it to mainline. I didn't
really care what -rc it was, because it was to go to stable too. Several
patches are still being queued for 3.10. Oh, which I should push out,
as I got distracted by my day job ;-)

Maybe it would be good to discuss when things should go into -rc and
stable at Kernel Summit.

-- Steve

Re: [ 00/34] 3.4.59-stable review

[Shuah Khan]

On 08/20/2013 10:03 AM, Greg Kroah-Hartman wrote:
> On Tue, Aug 20, 2013 at 08:53:24AM -0700, Hugh Dickins wrote:
>> On Tue, 20 Aug 2013, Greg Kroah-Hartman wrote:
>>> On Tue, Aug 20, 2013 at 07:36:00AM +0000, Berg, Johannes wrote:
>>>>>> [ 26/34] genetlink: fix family dump race
>>>>>
>>>>> Johannes, another strike against this patch :(
>>>>>
>>>>> Any chance on fixing it upstream and me sucking that fix in?
>>>>
>>>> Yeah, I'm trying to get that, but it's not clear to me how to fix it.
>>>> Where did you apply it? It was going to need some fixes but when the
>>>> first objection was raised I figured you were going to drop it for now
>>>> completely? Sorry for the mess :-(
>>>
>>> You're right, I'll drop this for 3.4, it doesn't make sense there.
>>
>> And you'll drop it from 3.0 and 3.10 also, I hope?
>
> It wasn't in 3.0, was it?  Oh crap, it was...
>
> 3.10, I'd rather have the "real" fix that ends up resolving the issue in
> Linus's tree also, instead of just dropping it.
>
> Especially as I just did the releases...
>

3.10 worked fine with no issues with this fix. I couldn't test 3.0 on 
this system because 3.4 is the minimum for my test system.

-- Shuah

-- 
Shuah Khan
Senior Linux Kernel Developer - Open Source Group
Samsung Research America(Silicon Valley)
shuah.kh@samsung.com | (970) 672-0658