2013-08-18 20:33:05

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 00/34] 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(-)


2013-08-18 20:33:12

by Greg Kroah-Hartman

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

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

Signed-off-by: Jiri Slaby <[email protected]>
Cc: Mikael Starvik <[email protected]>
Signed-off-by: Jesper Nilsson <[email protected]>
Cc: [email protected]
Cc: Geert Uytterhoeven <[email protected]>
Cc: Guenter Roeck <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
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 */

2013-08-18 20:33:29

by Greg Kroah-Hartman

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

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.

Signed-off-by: Geert Uytterhoeven <[email protected]>
Cc: Steven Rostedt <[email protected]>
Cc: Chris Zankel <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Cc: Guenter Roeck <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
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, "

2013-08-18 20:33:41

by Greg Kroah-Hartman

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

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.

Reported-by: Sage Weil <[email protected]>
Signed-off-by: Jan Kara <[email protected]>
Signed-off-by: "Theodore Ts'o" <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

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

2013-08-18 20:33:34

by Greg Kroah-Hartman

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

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

Acked-by: Chris Wilson <[email protected]>
Cc: Takashi Iwai <[email protected]>
Cc: Giacomo Comes <[email protected]>
Tested-by: Takashi Iwai <[email protected]>
Signed-Off-by: Daniel Vetter <[email protected]>
Cc: Haitao Zhang <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

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

2013-08-18 20:33:38

by Greg Kroah-Hartman

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

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.

Signed-off-by: Linus Torvalds <[email protected]>
Cc: Geert Uytterhoeven <[email protected]>
Cc: Guenter Roeck <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

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

2013-08-18 20:34:08

by Greg Kroah-Hartman

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

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.

Signed-off-by: Jiri Slaby <[email protected]>
Reported-by: Geert Uytterhoeven <[email protected]>
Signed-off-by: Jiri Kosina <[email protected]>
Cc: Guenter Roeck <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
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;
}

2013-08-18 20:33:32

by Greg Kroah-Hartman

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

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]

Signed-off-by: Markos Chandras <[email protected]>
Acked-by: Steven J. Hill <[email protected]>
Cc: [email protected]
Patchwork: https://patchwork.linux-mips.org/patch/5478/
Signed-off-by: Ralf Baechle <[email protected]>
Cc: Guenter Roeck <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

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

2013-08-18 20:34:35

by Greg Kroah-Hartman

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

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.

Signed-off-by: Paul Bolle <[email protected]>
Signed-off-by: Takashi Iwai <[email protected]>
Cc: Guenter Roeck <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

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

2013-08-18 20:47:54

by Greg Kroah-Hartman

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

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.

Reported-by: Andrew Morton <[email protected]>
Cc: Ralf Baechle <[email protected]>
Signed-off-by: Takashi Iwai <[email protected]>
Cc: Guenter Roeck <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

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

2013-08-18 20:48:19

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 05/34] microblaze: Update microblaze defconfigs

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.

Signed-off-by: Michal Simek <[email protected]>
Cc: Guenter Roeck <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

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

2013-08-18 20:48:40

by Greg Kroah-Hartman

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

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.

Reported-by: Thorsten Glaser <[email protected]>
Signed-off-by: Geert Uytterhoeven <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

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

2013-08-18 20:48:54

by Greg Kroah-Hartman

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

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

--- 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; \
})

2013-08-18 20:33:26

by Greg Kroah-Hartman

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

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.

Signed-off-by: Nicolas Dichtel <[email protected]>
Signed-off-by: Steffen Klassert <[email protected]>
Cc: Luis Henriques <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

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

2013-08-18 20:49:29

by Greg Kroah-Hartman

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

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.

Reported-by: Vince Weaver <[email protected]>
Tested-by: Vince Weaver <[email protected]>
Tested-by: Mark Rutland <[email protected]>
Signed-off-by: Will Deacon <[email protected]>
Signed-off-by: Russell King <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

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


2013-08-18 20:49:44

by Greg Kroah-Hartman

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

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]
Signed-off-by: Yonghua Zheng <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

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

2013-08-18 20:50:02

by Greg Kroah-Hartman

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

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.

Signed-off-by: Max Filippov <[email protected]>
Signed-off-by: Chris Zankel <[email protected]>
Cc: Geert Uytterhoeven <[email protected]>
Cc: Guenter Roeck <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
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 $@

2013-08-18 20:50:48

by Greg Kroah-Hartman

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

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.

Signed-off-by: Johan Hovold <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

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

2013-08-18 20:33:23

by Greg Kroah-Hartman

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

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]

Signed-off-by: Ralf Baechle <[email protected]>
Signed-off-by: Guenter Roeck <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---

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)


2013-08-18 20:51:03

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 27/34] usb: add two quirky touchscreen

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

Signed-off-by: Oliver Neukum <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
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 },

2013-08-18 20:51:26

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 26/34] genetlink: fix family dump race

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.

Reported-by: Andrei Otcheretianski <[email protected]>
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
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;
}


2013-08-18 20:51:46

by Greg Kroah-Hartman

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

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.

Signed-off-by: Stephane Grosjean <[email protected]>
Signed-off-by: Marc Kleine-Budde <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
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;
}


2013-08-18 20:52:06

by Greg Kroah-Hartman

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

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

Reported-and-tested-by: Justin Pearce <[email protected]>
Signed-off-by: Stanislaw Gruszka <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

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

2013-08-18 20:33:19

by Greg Kroah-Hartman

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

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 ]

Signed-off-by: Zhang Yi <[email protected]>
Reviewed-by: Jiang Biao <[email protected]>
Tested-by: Ma Chenggong <[email protected]>
Reviewed-by: 'Mel Gorman' <[email protected]>
Acked-by: 'Darren Hart' <[email protected]>
Cc: 'Peter Zijlstra' <[email protected]>
Link: http://lkml.kernel.org/r/000101ce71a6%24a83c5880%24f8b50980%24@com
Signed-off-by: Thomas Gleixner <[email protected]>
Cc: Mike Galbraith <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>


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

2013-08-18 20:52:24

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 23/34] iwl4965: set power mode early

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.

Signed-off-by: Stanislaw Gruszka <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

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

2013-08-18 20:52:44

by Greg Kroah-Hartman

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

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.

Signed-off-by: David S. Miller <[email protected]>
Cc: Guenter Roeck <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

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

2013-08-18 20:53:07

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 19/34] sparc32: add ucmpdi2

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.

Signed-off-by: Sam Ravnborg <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Cc: Guenter Roeck <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

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

2013-08-18 20:53:05

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 01/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().

Reported-and-tested-by: Vince Weaver <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
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;
}


2013-08-18 20:33:17

by Greg Kroah-Hartman

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

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.

Signed-off-by: Thomas Gleixner <[email protected]>
Acked-by: David Howells <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Cc: Guenter Roeck <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

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

2013-08-18 20:53:42

by Greg Kroah-Hartman

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

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.

Cc: [email protected]
Reported-by: Alexander Lyakas <[email protected]>
Signed-off-by: NeilBrown <[email protected]>
[adjust context to make it can be apply on top of 3.4 ]
Signed-off-by: Jack Wang <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

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

2013-08-18 20:53:59

by Greg Kroah-Hartman

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

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.

Reviewed-by: Matt Turner <[email protected]>
Cc: Richard Henderson <[email protected]>
Cc: Ivan Kokshaysky <[email protected]>
Tested-by: Thorsten Kranzkowski <[email protected]>
Signed-off-by: Will Deacon <[email protected]>
Signed-off-by: Michael Cree <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Cc: Guenter Roeck <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

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

2013-08-18 20:54:22

by Greg Kroah-Hartman

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

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.

Signed-off-by: Benjamin Herrenschmidt <[email protected]>
Cc: Guenter Roeck <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

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

2013-08-18 20:54:40

by Greg Kroah-Hartman

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

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.

Signed-off-by: Thomas Gleixner <[email protected]>
Acked-by: David Howells <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Cc: Guenter Roeck <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

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

2013-08-18 20:54:58

by Greg Kroah-Hartman

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

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'

Signed-off-by: Jesper Nilsson <[email protected]>
Cc: Guenter Roeck <[email protected]>
Cc: Geert Uytterhoeven <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

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

2013-08-18 20:55:28

by Greg Kroah-Hartman

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

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.

Signed-off-by: Paul Gortmaker <[email protected]>
Signed-off-by: Jesper Nilsson <[email protected]>
Cc: Geert Uytterhoeven <[email protected]>
Cc: Guenter Roeck <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

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


2013-08-19 01:49:13

by Guenter Roeck

[permalink] [raw]
Subject: Re: [ 00/34] 3.4.59-stable review

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

2013-08-19 18:02:30

by Shuah Khan

[permalink] [raw]
Subject: Re: [ 00/34] 3.4.59-stable review

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)
[email protected] | (970) 672-0658

2013-08-19 19:35:41

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [ 00/34] 3.4.59-stable review

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

2013-08-19 20:15:04

by Stefan Lippers-Hollmann

[permalink] [raw]
Subject: Re: [ 00/34] 3.4.59-stable review

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

2013-08-19 22:23:10

by Shuah Khan

[permalink] [raw]
Subject: Re: [ 00/34] 3.4.59-stable review

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)
[email protected] | (970) 672-0658

2013-08-19 22:30:39

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [ 00/34] 3.4.59-stable review

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

2013-08-19 22:31:39

by Shuah Khan

[permalink] [raw]
Subject: Re: [ 00/34] 3.4.59-stable review

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)
[email protected] | (970) 672-0658

2013-08-20 07:36:09

by Berg, Johannes

[permalink] [raw]
Subject: RE: [ 00/34] 3.4.59-stable review

> > [ 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?+???????+%?????ݶ??w??{.n?+????{??G?????{ay?ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m???? ????????I?

2013-08-20 15:22:13

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [ 00/34] 3.4.59-stable review

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

2013-08-20 15:33:25

by Berg, Johannes

[permalink] [raw]
Subject: RE: [ 00/34] 3.4.59-stable review

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

2013-08-20 15:53:47

by Hugh Dickins

[permalink] [raw]
Subject: Re: [ 00/34] 3.4.59-stable review

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

2013-08-20 16:02:08

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [ 00/34] 3.4.59-stable review

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

2013-08-20 16:25:29

by Hugh Dickins

[permalink] [raw]
Subject: Re: [ 00/34] 3.4.59-stable review

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

2013-08-20 16:43:53

by Steven Rostedt

[permalink] [raw]
Subject: Re: [ 00/34] 3.4.59-stable review

On Tue, 20 Aug 2013 09:25:05 -0700 (PDT)
Hugh Dickins <[email protected]> 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

2013-08-20 16:43:59

by Shuah Khan

[permalink] [raw]
Subject: Re: [ 00/34] 3.4.59-stable review

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)
[email protected] | (970) 672-0658