Skip to contentSkip to conversation

3.4.59-stable review

PATCH In review Greg Kroah-Hartman 7 participants 50 messages Aug 18, 2013 – Aug 20, 2013

Subsystems (27)
lore
Share & tools
lore

Greg Kroah-Hartman

author maintainer
#0 lore raw

cover 3.4.59-stable review

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 <[email protected]>

    Linux 3.4.59-rc1

Jan Kara <[email protected]>
jbd2: Fix use after free after error in jbd2_journal_dirty_metadata()

Geert Uytterhoeven <[email protected]>
m68k/atari: ARAnyM - Fix NatFeat module support

Andreas Schwab <[email protected]>
m68k: Truncate base in do_div()

Will Deacon <[email protected]>
ARM: 7809/1: perf: fix event validation for software group leaders

Geert Uytterhoeven <[email protected]>

    xtensa: replace xtensa-specific _f{data,text} by _s{data,text}

Max Filippov <[email protected]>
xtensa: fix linker script transformation for .text.unlikely

Johan Hovold <[email protected]>
USB: mos7720: fix broken control requests

Oliver Neukum <[email protected]>
usb: add two quirky touchscreen

Johannes Berg <[email protected]>
genetlink: fix family dump race

Stephane Grosjean <[email protected]>
can: pcan_usb: fix wrong memcpy() bytes length

Stanislaw Gruszka <[email protected]>
iwl4965: reset firmware after rfkill off

Stanislaw Gruszka <[email protected]>
iwl4965: set power mode early

Nicolas Dichtel <[email protected]>
af_key: initialize satype in key_notify_policy_flush()

Ralf Baechle <[email protected]>
MIPS: Rewrite pfn_valid to work in modules, too.

David S. Miller <[email protected]>
sparc32: Add ucmpdi2.o to obj-y instead of lib-y.

Sam Ravnborg <[email protected]>
sparc32: add ucmpdi2

NeilBrown <[email protected]>
md/raid1,raid10: use freeze_array in place of raise_barrier in various places.

Will Deacon <[email protected]>
alpha: makefile: don't enforce small data model for kernel builds

Benjamin Herrenschmidt <[email protected]>
powerpc/numa: Avoid stupid uninitialized warning from gcc

Thomas Gleixner <[email protected]>
frv: Use core allocator for task_struct

Thomas Gleixner <[email protected]>
frv: Use correct size for task_struct allocation

Zhang Yi <[email protected]>
futex: Take hugepages into account when generating futex_key

Jesper Nilsson <[email protected]>
CRIS: Add _sdata to vmlinux.lds.S

Paul Gortmaker <[email protected]>
cris: Remove old legacy "-traditional" flag from arch-v10/lib/Makefile

Jiri Slaby <[email protected]>
cris: posix_types.h, include asm-generic/posix_types.h

Linus Torvalds <[email protected]>
vm: add no-mmu vm_iomap_memory() stub

Jiri Slaby <[email protected]>
HID: microsoft: do not use compound literal - fix build

Paul Bolle <[email protected]>
sound: Fix make allmodconfig on MIPS correctly

Takashi Iwai <[email protected]>
sound: Fix make allmodconfig on MIPS

Michal Simek <[email protected]>
microblaze: Update microblaze defconfigs

Markos Chandras <[email protected]>
MIPS: Expose missing pci_io{map,unmap} declarations

Daniel Vetter <[email protected]>

    drm/i915/lvds: ditch ->prepare special case

yonghua zheng <[email protected]>
fs/proc/task_mmu.c: fix buffer overflow in add_page_map()

Stephen Boyd <[email protected]>
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(-)
author maintainer
#1 lore raw

PATCH 1/34 perf/arm: Fix armpmu_map_hw_event()

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

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

From: Stephen Boyd <[email protected]>

commit b88a2595b6d8aedbd275c07dfa784657b4f757eb upstream.

Fix constraint check in armpmu_map_hw_event().

---
 arch/arm/kernel/perf_event.c |    7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)
arch/arm/kernel/perf_event.c +6 -1
@@ -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;
 }
 
author maintainer
#2 lore raw

PATCH 2/34 fs/proc/task_mmu.c: fix buffer overflow in add_page_map()

In reply to Greg Kroah-Hartman

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

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

From: yonghua zheng <[email protected]>

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.

[[email protected]: document pagemapread.pos and .len units, fix PM_ENTRY_BYTES definition]
---
 fs/proc/task_mmu.c |    8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)
fs/proc/task_mmu.c +4 -4
@@ -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;
author maintainer
#3 lore raw

PATCH 3/34 drm/i915/lvds: ditch ->prepare special case

In reply to Greg Kroah-Hartman

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

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

From: Daniel Vetter <[email protected]>

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

---
 drivers/gpu/drm/i915/intel_lvds.c |    8 +-------
 1 file changed, 1 insertion(+), 7 deletions(-)
drivers/gpu/drm/i915/intel_lvds.c +1 -7
@@ -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)
author maintainer
#4 lore raw

PATCH 4/34 MIPS: Expose missing pci_io{map,unmap} declarations

In reply to Greg Kroah-Hartman

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

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

From: Markos Chandras <[email protected]>

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]

Patchwork: https://patchwork.linux-mips.org/patch/5478/

---
 arch/mips/Kconfig          |    2 +-
 arch/mips/include/asm/io.h |    5 +++++
 2 files changed, 6 insertions(+), 1 deletion(-)
arch/mips/Kconfig +1 -1
@@ -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
arch/mips/include/asm/io.h +5 -0
@@ -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)
 {
author maintainer
#5 lore raw

PATCH 5/34 microblaze: Update microblaze defconfigs

In reply to Greg Kroah-Hartman

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

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

From: Michal Simek <[email protected]>

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.

---
 arch/microblaze/configs/mmu_defconfig   |   49 ++++++++++++++--------
 arch/microblaze/configs/nommu_defconfig |   71 ++++++++++++++++++--------------
 2 files changed, 75 insertions(+), 45 deletions(-)
arch/microblaze/configs/mmu_defconfig +33 -16
@@ -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
arch/microblaze/configs/nommu_defconfig +42 -29

124 lines not on this page · raw message

author maintainer
#6 lore raw

PATCH 6/34 sound: Fix make allmodconfig on MIPS

In reply to Greg Kroah-Hartman

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

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

From: Takashi Iwai <[email protected]>

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.

---
 sound/oss/Kconfig |    1 +
 1 file changed, 1 insertion(+)
sound/oss/Kconfig +1 -0
@@ -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
author maintainer
#7 lore raw

PATCH 7/34 sound: Fix make allmodconfig on MIPS correctly

In reply to Greg Kroah-Hartman

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

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

From: Paul Bolle <[email protected]>

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.

---
 sound/oss/Kconfig |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
sound/oss/Kconfig +1 -1
@@ -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
author maintainer
#8 lore raw

PATCH 8/34 HID: microsoft: do not use compound literal - fix build

In reply to Greg Kroah-Hartman

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

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

From: Jiri Slaby <[email protected]>

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.

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

PATCH 9/34 vm: add no-mmu vm_iomap_memory() stub

In reply to Greg Kroah-Hartman

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

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

From: Linus Torvalds <[email protected]>

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.

---
 mm/nommu.c |   10 ++++++++++
 1 file changed, 10 insertions(+)
mm/nommu.c +10 -0
@@ -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)
 {
author maintainer
#10 lore raw

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

In reply to Greg Kroah-Hartman

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

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

From: Jiri Slaby <[email protected]>

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

---
 arch/cris/include/asm/posix_types.h |    2 ++
 1 file changed, 2 insertions(+)
arch/cris/include/asm/posix_types.h +2 -0
@@ -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 */
author maintainer
#11 lore raw

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

In reply to Greg Kroah-Hartman

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

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

From: Paul Gortmaker <[email protected]>

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.

---
 arch/cris/arch-v10/lib/Makefile |    3 ---
 1 file changed, 3 deletions(-)
arch/cris/arch-v10/lib/Makefile +0 -3
@@ -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
 
author maintainer
#12 lore raw

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

In reply to Greg Kroah-Hartman

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

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

From: Jesper Nilsson <[email protected]>

commit 473e162eea465e60578edb93341752e7f1c1dacc upstream.

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

---
 arch/cris/kernel/vmlinux.lds.S |    1 +
 1 file changed, 1 insertion(+)
arch/cris/kernel/vmlinux.lds.S +1 -0
@@ -52,6 +52,7 @@ SECTIONS
 
 	EXCEPTION_TABLE(4)
 
+	_sdata = .;
 	RODATA
 
 	. = ALIGN (4);
author maintainer
#13 lore raw

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

In reply to Greg Kroah-Hartman

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

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

From: Zhang Yi <[email protected]>

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 ]

---
 include/linux/hugetlb.h |   16 ++++++++++++++++
 kernel/futex.c          |    3 ++-
 mm/hugetlb.c            |   17 +++++++++++++++++
 3 files changed, 35 insertions(+), 1 deletion(-)
include/linux/hugetlb.h +16 -0
@@ -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 */
kernel/futex.c +2 -1
@@ -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);
mm/hugetlb.c +17 -0
@@ -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;
author maintainer
#14 lore raw

PATCH 14/34 frv: Use correct size for task_struct allocation

In reply to Greg Kroah-Hartman

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

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

From: Thomas Gleixner <[email protected]>

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.

---
 arch/frv/kernel/process.c |    9 ++-------
 1 file changed, 2 insertions(+), 7 deletions(-)
arch/frv/kernel/process.c +2 -7
@@ -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)
author maintainer
#15 lore raw

PATCH 15/34 frv: Use core allocator for task_struct

In reply to Greg Kroah-Hartman

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

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

From: Thomas Gleixner <[email protected]>

commit c6ae063aaf3786b9db7f19a90bf4ed8aaebb7f90 upstream.

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

---
 arch/frv/include/asm/thread_info.h |    2 --
 arch/frv/kernel/process.c          |   10 ----------
 2 files changed, 12 deletions(-)
arch/frv/include/asm/thread_info.h +0 -2
@@ -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
arch/frv/kernel/process.c +0 -10
@@ -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
author maintainer
#16 lore raw

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

In reply to Greg Kroah-Hartman

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

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

From: Benjamin Herrenschmidt <[email protected]>

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.

---
 arch/powerpc/mm/numa.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
arch/powerpc/mm/numa.c +1 -1
@@ -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)
author maintainer
#17 lore raw

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

In reply to Greg Kroah-Hartman

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

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

From: Will Deacon <[email protected]>

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.

---
 arch/alpha/Makefile |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
arch/alpha/Makefile +1 -1
@@ -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
author maintainer
#18 lore raw

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

In reply to Greg Kroah-Hartman

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

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

From: NeilBrown <[email protected]>

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.

[adjust context to make it can be apply on top of 3.4 ]
---
 drivers/md/raid1.c  |   22 +++++++++++-----------
 drivers/md/raid10.c |   14 +++++++-------
 2 files changed, 18 insertions(+), 18 deletions(-)
drivers/md/raid1.c +11 -11
@@ -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);
drivers/md/raid10.c +7 -7
@@ -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
author maintainer
#19 lore raw

PATCH 19/34 sparc32: add ucmpdi2

In reply to Greg Kroah-Hartman

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

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

From: Sam Ravnborg <[email protected]>

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.

---
 arch/sparc/lib/Makefile  |    2 +-
 arch/sparc/lib/ucmpdi2.c |   19 +++++++++++++++++++
 2 files changed, 20 insertions(+), 1 deletion(-)
arch/sparc/lib/Makefile +1 -1
@@ -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
arch/sparc/lib/ucmpdi2.c new file +19 -0
@@ -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);
author maintainer
#20 lore raw

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

In reply to Greg Kroah-Hartman

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

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

From: "David S. Miller" <[email protected]>

commit 74c7b28953d4eaa6a479c187aeafcfc0280da5e8 upstream.

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

---
 arch/sparc/lib/Makefile |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
arch/sparc/lib/Makefile +2 -2
@@ -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
author maintainer
#21 lore raw

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

In reply to Greg Kroah-Hartman

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

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

From: Ralf Baechle <[email protected]>

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]

---

 arch/mips/include/asm/page.h |   17 +++++++++--------
 1 file changed, 9 insertions(+), 8 deletions(-)
arch/mips/include/asm/page.h +9 -8
@@ -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)
 
author maintainer
#22 lore raw

PATCH 22/34 af_key: initialize satype in key_notify_policy_flush()

In reply to Greg Kroah-Hartman

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

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

From: Nicolas Dichtel <[email protected]>

commit 85dfb745ee40232876663ae206cba35f24ab2a40 upstream.

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

---
 net/key/af_key.c |    1 +
 1 file changed, 1 insertion(+)
net/key/af_key.c +1 -0
@@ -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);
author maintainer
#23 lore raw

PATCH 23/34 iwl4965: set power mode early

In reply to Greg Kroah-Hartman

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

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

From: Stanislaw Gruszka <[email protected]>

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.

---
 drivers/net/wireless/iwlegacy/4965-mac.c |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)
drivers/net/wireless/iwlegacy/4965-mac.c +3 -3
@@ -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:
author maintainer
#24 lore raw

PATCH 24/34 iwl4965: reset firmware after rfkill off

In reply to Greg Kroah-Hartman

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

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

From: Stanislaw Gruszka <[email protected]>

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

---
 drivers/net/wireless/iwlegacy/4965-mac.c |   10 +++++-----
 drivers/net/wireless/iwlegacy/common.c   |    1 +
 2 files changed, 6 insertions(+), 5 deletions(-)
drivers/net/wireless/iwlegacy/4965-mac.c +5 -5
@@ -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;
drivers/net/wireless/iwlegacy/common.c +1 -0
@@ -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,
author maintainer
#25 lore raw

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

In reply to Greg Kroah-Hartman

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

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

From: Stephane Grosjean <[email protected]>

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.

---
 drivers/net/can/usb/peak_usb/pcan_usb.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/can/usb/peak_usb/pcan_usb.c +1 -1
@@ -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;
 	}
 
author maintainer
#26 lore raw

PATCH 26/34 genetlink: fix family dump race

In reply to Greg Kroah-Hartman

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

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

From: Johannes Berg <[email protected]>

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.

---
 net/netlink/genetlink.c |    7 +++++++
 1 file changed, 7 insertions(+)
net/netlink/genetlink.c +7 -0
@@ -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;
 }
 
author maintainer
#27 lore raw

PATCH 27/34 usb: add two quirky touchscreen

In reply to Greg Kroah-Hartman

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

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

From: Oliver Neukum <[email protected]>

commit 304ab4ab079a8ed03ce39f1d274964a532db036b upstream.

These devices tend to become unresponsive after S3

---
 drivers/usb/core/quirks.c |    6 ++++++
 1 file changed, 6 insertions(+)
drivers/usb/core/quirks.c +6 -0
@@ -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 },
author maintainer
#28 lore raw

PATCH 28/34 USB: mos7720: fix broken control requests

In reply to Greg Kroah-Hartman

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

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

From: Johan Hovold <[email protected]>

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.

---
 drivers/usb/serial/mos7720.c |   21 ++++++++++++++-------
 1 file changed, 14 insertions(+), 7 deletions(-)
drivers/usb/serial/mos7720.c +14 -7
@@ -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);
author maintainer
#29 lore raw

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

In reply to Greg Kroah-Hartman

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

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

From: Max Filippov <[email protected]>

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.

---
 arch/xtensa/kernel/Makefile |    1 +
 1 file changed, 1 insertion(+)
arch/xtensa/kernel/Makefile +1 -0
@@ -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     $@
author maintainer
#30 lore raw

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

In reply to Greg Kroah-Hartman

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

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

From: Geert Uytterhoeven <[email protected]>

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.

---
 arch/xtensa/kernel/vmlinux.lds.S |    3 +--
 arch/xtensa/mm/init.c            |    6 +++---
 2 files changed, 4 insertions(+), 5 deletions(-)
arch/xtensa/kernel/vmlinux.lds.S +1 -2
@@ -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 = .;
 
arch/xtensa/mm/init.c +3 -3
@@ -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, "
author maintainer
#31 lore raw

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

In reply to Greg Kroah-Hartman

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

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

From: Will Deacon <[email protected]>

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.

---
 arch/arm/kernel/perf_event.c |    3 +++
 1 file changed, 3 insertions(+)
arch/arm/kernel/perf_event.c +3 -0
@@ -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;
 
author maintainer
#32 lore raw

PATCH 32/34 m68k: Truncate base in do_div()

In reply to Greg Kroah-Hartman

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

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

From: Andreas Schwab <[email protected]>

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(-)
arch/m68k/include/asm/div64.h +5 -4
@@ -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;							\
 })
author maintainer
#33 lore raw

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

In reply to Greg Kroah-Hartman

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

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

From: Geert Uytterhoeven <[email protected]>

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.

---
 arch/m68k/emu/natfeat.c |   23 +++++++++++++++++++----
 1 file changed, 19 insertions(+), 4 deletions(-)
arch/m68k/emu/natfeat.c +19 -4
@@ -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];
author maintainer
#34 lore raw

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

In reply to Greg Kroah-Hartman

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

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

From: Jan Kara <[email protected]>

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.

---
 fs/ext4/ext4_jbd2.c |    8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)
fs/ext4/ext4_jbd2.c +4 -4
@@ -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)
#35 lore raw
In reply to Greg Kroah-Hartman
Quoted 10 lines · 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.

Quoted 7 lines

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

#36 lore raw
In reply to Greg Kroah-Hartman
Quoted 13 lines · 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.

Quoted 8 lines

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

	kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.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)
[email protected] | (970) 672-0658

author maintainer
#37 lore raw
Quoted 23 lines · Shuah Khan
Quoted 13 lines · 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.

Quoted 8 lines

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

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

and the diffstat can be found below.

thanks,

greg k-h

Quoted 6 lines

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.

Quoted 9 lines

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

#38 lore raw

Hi

Quoted 2 lines · Greg Kroah-Hartman
Quoted 1 line · Shuah Khan

On 08/18/2013 02:34 PM, Greg Kroah-Hartman wrote:

[…]

Quoted 9 lines
Quoted 4 lines

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

#39 lore raw
Quoted 37 lines · Stefan Lippers-Hollmann

Hi

Quoted 2 lines · Greg Kroah-Hartman
Quoted 1 line · Shuah Khan

On 08/18/2013 02:34 PM, Greg Kroah-Hartman wrote:

[…]

Quoted 9 lines
Quoted 4 lines

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

Quoted 6 lines

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

Signature · 4 lines
Shuah Khan
Senior Linux Kernel Developer - Open Source Group
Samsung Research America(Silicon Valley)
[email protected] | (970) 672-0658
author maintainer
#40 lore raw
Quoted 45 lines · Shuah Khan
Quoted 37 lines · Stefan Lippers-Hollmann

Hi

Quoted 2 lines · Greg Kroah-Hartman
Quoted 1 line · Shuah Khan

On 08/18/2013 02:34 PM, Greg Kroah-Hartman wrote:

[…]

Quoted 9 lines
Quoted 4 lines

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

Quoted 6 lines

Regards
Stefan Lippers-Hollmann

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

Quoted 5 lines

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

#41 lore raw
Quoted 5 lines
Quoted 1 line

[ 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

Signature · 8 lines
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
author maintainer
#42 lore raw
Quoted 10 lines · Johannes
Quoted 5 lines
Quoted 1 line

[ 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

#43 lore raw
Quoted 6 lines
Quoted 4 lines

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

Signature · 8 lines
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
#44 lore raw
In reply to Greg Kroah-Hartman
Quoted 5 lines · Greg Kroah-Hartman
Quoted 4 lines · Johannes
Quoted 4 lines
Quoted 1 line

[ 26/34] genetlink: fix family dump race

Johannes, another strike against this patch :(

Quoted 8 lines
Quoted 6 lines
Quoted 1 line

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

author maintainer
#45 lore raw
Quoted 8 lines · Hugh Dickins
Quoted 7 lines · Greg Kroah-Hartman
Quoted 6 lines · Johannes
Quoted 5 lines
Quoted 1 line

[ 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?

Quoted 8 lines
Quoted 6 lines
Quoted 4 lines

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

#46 lore raw
Quoted 14 lines · Greg Kroah-Hartman
Quoted 13 lines · Hugh Dickins
Quoted 12 lines · Greg Kroah-Hartman
Quoted 10 lines · Johannes
Quoted 5 lines
Quoted 1 line

[ 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 :-(

Quoted 8 lines
Quoted 3 lines
Quoted 1 line

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").

Quoted 2 lines

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

#47 lore raw
Quoted 6 lines · On Tue, 20 Aug 2013 09:25:05 -0700 (PDT) Hugh Dickins <[email protected]> wrote:
Quoted 2 lines

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

#48 lore raw
In reply to Greg Kroah-Hartman
Quoted 16 lines · Greg Kroah-Hartman
Quoted 15 lines · Hugh Dickins
Quoted 13 lines · Greg Kroah-Hartman
Quoted 10 lines · Johannes
Quoted 5 lines
Quoted 1 line

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

Quoted 9 lines
Quoted 1 line

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

Signature · 4 lines
Shuah Khan
Senior Linux Kernel Developer - Open Source Group
Samsung Research America(Silicon Valley)
[email protected] | (970) 672-0658
#49 lore raw
In reply to Shuah Khan
Quoted 46 lines · Shuah Khan
Quoted 38 lines · Stefan Lippers-Hollmann

Hi

Quoted 2 lines · Greg Kroah-Hartman
Quoted 1 line · Shuah Khan

On 08/18/2013 02:34 PM, Greg Kroah-Hartman wrote:

[…]

Quoted 9 lines
Quoted 4 lines

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

Quoted 6 lines

Regards
Stefan Lippers-Hollmann

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

Quoted 9 lines

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

Signature · 4 lines
Shuah Khan
Senior Linux Kernel Developer - Open Source Group
Samsung Research America(Silicon Valley)
[email protected] | (970) 672-0658