2013-08-09 01:58:23

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 000/102] 3.10.6-stable review

This is the start of the stable review cycle for the 3.10.6 release.
There are 102 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.

Responses should be made by Sun Aug 11 01:46:31 UTC 2013.
Anything received after that time might be too late.

The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.10.6-rc1.gz
and the diffstat can be found below.

thanks,

greg k-h

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

Greg Kroah-Hartman <[email protected]>
Linux 3.10.6-rc1

Johannes Berg <[email protected]>
iwlwifi: dvm: don't send BT_CONFIG on devices w/o Bluetooth

David Spinadel <[email protected]>
iwlwifi: mvm: set SSID bits for passive channels

Jack Morgenstein <[email protected]>
net/mlx4_core: VFs must ignore the enable_64b_cqe_eqe module param

Or Gerlitz <[email protected]>
net/mlx4_core: Don't give VFs MAC addresses which are derived from the PF MAC

Neil Horman <[email protected]>
8139cp: Add dma_mapping_error checking

Joe Perches <[email protected]>
ndisc: Add missing inline to ndisc_addr_option_pad

Dan Carpenter <[email protected]>
net_sched: info leak in atm_tc_dump_class()

Eric Dumazet <[email protected]>
atl1c: use custom skb allocator

Dan Carpenter <[email protected]>
af_key: more info leaks in pfkey messages

David S. Miller <[email protected]>
net_sched: Fix stack info leak in cbq_dump_wrr().

Stanislaw Gruszka <[email protected]>
genetlink: release cb_lock before requesting additional module

Eric Dumazet <[email protected]>
usbnet: do not pretend to support SG/TSO

Hannes Frederic Sowa <[email protected]>
ipv6: take rtnl_lock and mark mrt6 table as freed on namespace cleanup

Ben Hutchings <[email protected]>
sfc: Enable RX scatter for flows steered by RFS

Michal Tesar <[email protected]>
sysctl net: Keep tcp_syn_retries inside the boundary

Dan Carpenter <[email protected]>
arcnet: cleanup sizeof parameter

Christian Eggers <[email protected]>
spi: spi-davinci: Fix direction in dma_map_single()

Neil Horman <[email protected]>
x86/iommu/vt-d: Expand interrupt remapping quirk to cover x58 chipset

Oleg Nesterov <[email protected]>
userns: unshare_userns(&cred) should not populate cred on failure

Shaohua Li <[email protected]>
workqueue: copy workqueue_attrs with all fields

Martin Schwidefsky <[email protected]>
s390/bitops: fix find_next_bit_left

Heiko Carstens <[email protected]>
s390: add support for IBM zBC12 machine

Daniel Vetter <[email protected]>
drm/i915: make SDVO TV-out work for multifunction devices

Liu Bo <[email protected]>
Btrfs: fix crash regarding to ulist_add_merge

H.J. Lu <[email protected]>
x86, fpu: correct the asm constraints for fxsave, unbreak mxcsr.daz

Christian König <[email protected]>
drm/radeon: never unpin UVD bo v3

Li Zefan <[email protected]>
cgroup: fix umount vs cgroup_cfts_commit() race

Dan Carpenter <[email protected]>
fanotify: info leak in copy_event_to_user()

Stéphane Marchesin <[email protected]>
drm/i915: Preserve the DDI_A_4_LANES bit from the bios

Roger Pau Monne <[email protected]>
xen-blkfront: use a different scatterlist for each request

Alex Deucher <[email protected]>
drm/radeon: Disable dma rings for bo moves on r6xx

Yinghai Lu <[email protected]>
PCI: Retry allocation of only the resource type that failed

Yinghai Lu <[email protected]>
PCI: pciehp: Fix null pointer deref when hot-removing SR-IOV device

Rafael J. Wysocki <[email protected]>
Revert "cpuidle: Quickly notice prediction failure for repeat mode"

Rafael J. Wysocki <[email protected]>
cpufreq: Fix cpufreq driver module refcount balance after suspend/resume

Rafael J. Wysocki <[email protected]>
Revert "cpuidle: Quickly notice prediction failure in general case"

Lan Tianyu <[email protected]>
ACPI / battery: Fix parsing _BIX return value

Jiang Liu <[email protected]>
zram: protect sysfs handler from invalid memory access

Jiang Liu <[email protected]>
zram: avoid access beyond the zram device

Jiang Liu <[email protected]>
zram: avoid double free in function zram_bvec_write()

Jiang Liu <[email protected]>
zram: destroy all devices on error recovery path in zram_init()

Jiang Liu <[email protected]>
zram: use zram->lock to protect zram_free_page() in swap free notify path

Jiang Liu <[email protected]>
zram: avoid invalid memory access in zram_exit()

Avinash Patil <[email protected]>
mwifiex: fix wrong data rates in P2P client

Avinash Patil <[email protected]>
mwifiex: check for bss_role instead of bss_mode for STA operations

Tomasz Moń <[email protected]>
mwifiex: Add missing endian conversion.

Stanislaw Gruszka <[email protected]>
rt2x00: fix stop queue

J. Bruce Fields <[email protected]>
svcrpc: fix kfree oops in gss-proxy code

J. Bruce Fields <[email protected]>
svcrpc: fix gss_rpc_upcall create error

J. Bruce Fields <[email protected]>
svcrpc: fix gss-proxy xdr decoding oops

Adam Lee <[email protected]>
Bluetooth: fix wrong use of PTR_ERR() in btusb

Cho, Yu-Chen <[email protected]>
Bluetooth: Add support for Mediatek Bluetooth device [0e8d:763f]

AceLan Kao <[email protected]>
Bluetooth: Add support for Atheros [0cf3:e003]

AceLan Kao <[email protected]>
Bluetooth: Add support for Atheros [0cf3:3121]

Sujith Manoharan <[email protected]>
Bluetooth: ath3k: Add support for ID 0x13d3/0x3402

Stanislaw Gruszka <[email protected]>
Bluetooth: ath3k: don't use stack memory for DMA

Thomas Loo <[email protected]>
Bluetooth: ath3k: Add support for Fujitsu Lifebook UH5x2 [04c5:1330]

Jaganath Kanakkassery <[email protected]>
Bluetooth: Fix invalid length check in l2cap_information_rsp()

Larry Finger <[email protected]>
ath: wil6210: Fix build error

Jacob Keller <[email protected]>
ixgbe: Fix Tx Hang issue with lldpad on 82598EB

Stanislaw Gruszka <[email protected]>
mac80211: fix monitor interface suspend crash regression

Johannes Berg <[email protected]>
mac80211: fix ethtool stats for non-station interfaces

Johannes Berg <[email protected]>
mac80211: fix duplicate retransmission detection

Felix Fietkau <[email protected]>
mac80211/minstrel_ht: fix cck rate sampling

Felix Fietkau <[email protected]>
mac80211/minstrel: fix NULL pointer dereference issue

Michal Kazior <[email protected]>
nl80211: fix mgmt tx status and testmode reporting for netns

Oleksij Rempel <[email protected]>
ath9k_htc: reboot firmware if it was loaded

Oleksij Rempel <[email protected]>
ath9k_htc: do some initial hardware configuration

Johannes Berg <[email protected]>
iwlwifi: mvm: fix flushing not started aggregation sessions

Emmanuel Grumbach <[email protected]>
iwlwifi: add DELL SKU for 5150 HMC

Johannes Berg <[email protected]>
iwlwifi: mvm: refuse connection to APs with BI < 16

David Spinadel <[email protected]>
iwlwifi: mvm: fix bug in scan ssid

Emmanuel Grumbach <[email protected]>
iwlwifi: mvm: fix L2P BA ressources leak

Johan Hovold <[email protected]>
USB: mos7840: fix pointer casts

Johan Hovold <[email protected]>
USB: mos7840: fix race in led handling

Johan Hovold <[email protected]>
USB: mos7840: fix device-type detection

Johan Hovold <[email protected]>
USB: mos7840: fix race in register handling

Lars-Peter Clausen <[email protected]>
dma: pl330: Fix cyclic transfers

Uwe Kleine-König <[email protected]>
serial/mxs-auart: increase time to wait for transmitter to become idle

Axel Lin <[email protected]>
serial: arc_uart: Fix module alias

Uwe Kleine-König <[email protected]>
serial/mxs-auart: fix race condition in interrupt handler

Vinod Koul <[email protected]>
ALSA: compress: fix the return value for SNDRV_COMPRESS_VERSION

Takashi Iwai <[email protected]>
ALSA: hda - Fix missing fixup for Mac Mini with STAC9221

Vivien Didelot <[email protected]>
hwmon: (max6697) fix MAX6581 ideality

Thomas Bogendoerfer <[email protected]>
parisc: Fix interrupt routing for C8000 serial ports

John David Anglin <[email protected]>
parisc: Fix cache routines to ignore vma's with an invalid pfn

Alex Ivanov <[email protected]>
parisc: agp/parisc-agp: allow binding of user memory to the AGP GART

Robert Jennings <[email protected]>
powerpc: VPHN topology change updates all siblings

Will Deacon <[email protected]>
ARM: 7791/1: a.out: remove partial a.out support

Catalin Marinas <[email protected]>
ARM: 7790/1: Fix deferred mm switch on VIVT processors

Will Deacon <[email protected]>
ARM: 7784/1: mm: ensure SMP alternates assemble to exactly 4 bytes with Thumb-2

Aaro Koskinen <[email protected]>
powerpc/windfarm: Fix noisy slots-fan on Xserve (rm31)

Russell King <[email protected]>
ARM: fix nommu builds with 48be69a02 (ARM: move signal handlers into a vdso-like page)

Russell King <[email protected]>
ARM: fix a cockup in 48be69a02 (ARM: move signal handlers into a vdso-like page)

Russell King <[email protected]>
ARM: make vectors page inaccessible from userspace

Russell King <[email protected]>
ARM: move signal handlers into a vdso-like page

Russell King <[email protected]>
ARM: allow kuser helpers to be removed from the vector page

Russell King <[email protected]>
ARM: update FIQ support for relocation of vectors

Russell King <[email protected]>
ARM: use linker magic for vectors and vector stubs

Russell King <[email protected]>
ARM: move vector stubs

Russell King <[email protected]>
ARM: poison memory between kuser helpers

Russell King <[email protected]>
ARM: poison the vectors page


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

Diffstat:

Makefile | 4 +-
arch/arm/Kconfig | 4 +-
arch/arm/include/asm/a.out-core.h | 45 -------
arch/arm/include/asm/elf.h | 6 +
arch/arm/include/asm/mmu.h | 3 +
arch/arm/include/asm/mmu_context.h | 20 ++-
arch/arm/include/asm/page.h | 2 +
arch/arm/include/asm/processor.h | 4 -
arch/arm/include/asm/thread_info.h | 1 -
arch/arm/include/uapi/asm/Kbuild | 1 -
arch/arm/include/uapi/asm/a.out.h | 34 -----
arch/arm/kernel/entry-armv.S | 103 +++++++-------
arch/arm/kernel/fiq.c | 19 ++-
arch/arm/kernel/process.c | 46 ++++++-
arch/arm/kernel/signal.c | 52 ++++++-
arch/arm/kernel/signal.h | 12 --
arch/arm/kernel/traps.c | 46 ++++---
arch/arm/kernel/vmlinux.lds.S | 17 +++
arch/arm/mm/Kconfig | 34 +++++
arch/arm/mm/mmu.c | 14 +-
arch/arm/mm/proc-v7-2level.S | 2 +-
arch/arm/mm/proc-v7-3level.S | 2 +-
arch/arm/mm/proc-v7.S | 11 +-
arch/parisc/include/asm/parisc-device.h | 3 +
arch/parisc/kernel/cache.c | 135 ++++++++++---------
arch/parisc/kernel/inventory.c | 1 +
arch/powerpc/include/asm/smp.h | 4 +
arch/powerpc/mm/numa.c | 59 +++++---
arch/s390/Kconfig | 7 +-
arch/s390/include/asm/bitops.h | 2 +-
arch/s390/kernel/setup.c | 1 +
arch/s390/mm/init.c | 1 +
arch/s390/oprofile/init.c | 2 +-
arch/x86/kernel/early-quirks.c | 14 +-
arch/x86/kernel/i387.c | 2 +-
drivers/acpi/battery.c | 2 +
drivers/block/xen-blkfront.c | 36 +++--
drivers/bluetooth/ath3k.c | 46 +++++--
drivers/bluetooth/btusb.c | 21 ++-
drivers/char/agp/parisc-agp.c | 6 +-
drivers/cpufreq/cpufreq.c | 19 +--
drivers/cpuidle/governors/menu.c | 106 +--------------
drivers/dma/pl330.c | 93 +++++++++----
drivers/gpu/drm/i915/intel_ddi.c | 10 +-
drivers/gpu/drm/i915/intel_display.c | 8 +-
drivers/gpu/drm/i915/intel_drv.h | 2 +-
drivers/gpu/drm/radeon/radeon.h | 3 +-
drivers/gpu/drm/radeon/radeon_asic.c | 8 +-
drivers/gpu/drm/radeon/radeon_fence.c | 2 +-
drivers/gpu/drm/radeon/radeon_uvd.c | 100 +++++++-------
drivers/gpu/drm/radeon/rv770.c | 2 +-
drivers/hwmon/max6697.c | 4 +-
drivers/macintosh/windfarm_rm31.c | 18 +--
drivers/net/arcnet/arcnet.c | 2 +-
drivers/net/ethernet/atheros/atl1c/atl1c.h | 3 +
drivers/net/ethernet/atheros/atl1c/atl1c_main.c | 40 +++++-
drivers/net/ethernet/intel/ixgbe/ixgbe_dcb_82598.c | 3 +-
drivers/net/ethernet/mellanox/mlx4/fw.c | 11 +-
drivers/net/ethernet/mellanox/mlx4/main.c | 2 +-
drivers/net/ethernet/realtek/8139cp.c | 48 ++++++-
drivers/net/ethernet/sfc/filter.c | 4 +-
drivers/net/usb/ax88179_178a.c | 9 +-
drivers/net/usb/smsc75xx.c | 12 +-
drivers/net/wireless/ath/ath9k/hif_usb.c | 4 +-
drivers/net/wireless/ath/ath9k/htc_drv_init.c | 1 +
drivers/net/wireless/ath/wil6210/debugfs.c | 4 +-
drivers/net/wireless/iwlwifi/dvm/main.c | 2 +-
drivers/net/wireless/iwlwifi/mvm/fw-api-scan.h | 1 -
drivers/net/wireless/iwlwifi/mvm/mac80211.c | 16 +++
drivers/net/wireless/iwlwifi/mvm/scan.c | 15 +--
drivers/net/wireless/iwlwifi/mvm/sta.c | 19 ++-
drivers/net/wireless/iwlwifi/pcie/drv.c | 1 +
drivers/net/wireless/mwifiex/cfg80211.c | 4 +-
drivers/net/wireless/mwifiex/cfp.c | 3 +-
drivers/net/wireless/mwifiex/join.c | 6 +-
drivers/net/wireless/mwifiex/sdio.c | 4 +-
drivers/net/wireless/rt2x00/rt2x00queue.c | 18 ++-
drivers/parisc/iosapic.c | 38 ++++--
drivers/pci/hotplug/pciehp_pci.c | 9 +-
drivers/pci/setup-bus.c | 69 +++++++++-
drivers/spi/spi-davinci.c | 2 +-
drivers/staging/zram/zram_drv.c | 38 ++++--
drivers/staging/zram/zram_drv.h | 5 +-
drivers/staging/zram/zram_sysfs.c | 2 +
drivers/tty/serial/8250/8250_gsc.c | 3 +-
drivers/tty/serial/arc_uart.c | 2 +-
drivers/tty/serial/mxs-auart.c | 38 +++---
drivers/usb/serial/mos7840.c | 150 ++++++++++++---------
fs/btrfs/ulist.c | 15 +++
fs/notify/fanotify/fanotify_user.c | 1 +
include/linux/tick.h | 6 -
include/net/ndisc.h | 2 +-
kernel/cgroup.c | 9 +-
kernel/time/tick-sched.c | 9 +-
kernel/user_namespace.c | 13 +-
kernel/workqueue.c | 12 ++
net/bluetooth/l2cap_core.c | 2 +-
net/ipv4/sysctl_net_ipv4.c | 6 +-
net/ipv6/ip6mr.c | 5 +
net/key/af_key.c | 4 +
net/mac80211/cfg.c | 2 +
net/mac80211/pm.c | 7 +-
net/mac80211/rc80211_minstrel.c | 3 +-
net/mac80211/rc80211_minstrel_ht.c | 10 +-
net/mac80211/rx.c | 10 +-
net/netlink/genetlink.c | 2 +
net/sched/sch_atm.c | 1 +
net/sched/sch_cbq.c | 1 +
net/sunrpc/auth_gss/gss_rpc_upcall.c | 3 +-
net/sunrpc/auth_gss/gss_rpc_xdr.c | 9 +-
net/wireless/nl80211.c | 7 +-
sound/core/compress_offload.c | 2 +-
sound/pci/hda/hda_auto_parser.c | 2 +-
sound/pci/hda/patch_sigmatel.c | 1 +
114 files changed, 1178 insertions(+), 753 deletions(-)


2013-08-09 01:58:28

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 005/102] ARM: update FIQ support for relocation of vectors

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

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

From: Russell King <[email protected]>

commit e39e3f3ebfef03450cf7bfa7a974a8c61f7980c8 upstream.

FIQ should no longer copy the FIQ code into the user visible vector
page. Instead, it should use the hidden page. This change makes
that happen.

Acked-by: Nicolas Pitre <[email protected]>
Signed-off-by: Russell King <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/arm/kernel/entry-armv.S | 3 +++
arch/arm/kernel/fiq.c | 19 ++++++++++++++-----
2 files changed, 17 insertions(+), 5 deletions(-)

--- a/arch/arm/kernel/entry-armv.S
+++ b/arch/arm/kernel/entry-armv.S
@@ -1119,6 +1119,9 @@ vector_addrexcptn:
vector_fiq:
subs pc, lr, #4

+ .globl vector_fiq_offset
+ .equ vector_fiq_offset, vector_fiq
+
.section .vectors, "ax", %progbits
__vectors_start:
W(b) vector_rst
--- a/arch/arm/kernel/fiq.c
+++ b/arch/arm/kernel/fiq.c
@@ -47,6 +47,11 @@
#include <asm/irq.h>
#include <asm/traps.h>

+#define FIQ_OFFSET ({ \
+ extern void *vector_fiq_offset; \
+ (unsigned)&vector_fiq_offset; \
+ })
+
static unsigned long no_fiq_insn;

/* Default reacquire function
@@ -80,13 +85,16 @@ int show_fiq_list(struct seq_file *p, in
void set_fiq_handler(void *start, unsigned int length)
{
#if defined(CONFIG_CPU_USE_DOMAINS)
- memcpy((void *)0xffff001c, start, length);
+ void *base = (void *)0xffff0000;
#else
- memcpy(vectors_page + 0x1c, start, length);
+ void *base = vectors_page;
#endif
- flush_icache_range(0xffff001c, 0xffff001c + length);
+ unsigned offset = FIQ_OFFSET;
+
+ memcpy(base + offset, start, length);
+ flush_icache_range(0xffff0000 + offset, 0xffff0000 + offset + length);
if (!vectors_high())
- flush_icache_range(0x1c, 0x1c + length);
+ flush_icache_range(offset, offset + length);
}

int claim_fiq(struct fiq_handler *f)
@@ -144,6 +152,7 @@ EXPORT_SYMBOL(disable_fiq);

void __init init_FIQ(int start)
{
- no_fiq_insn = *(unsigned long *)0xffff001c;
+ unsigned offset = FIQ_OFFSET;
+ no_fiq_insn = *(unsigned long *)(0xffff0000 + offset);
fiq_start = start;
}

2013-08-09 01:58:34

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 010/102] ARM: fix nommu builds with 48be69a02 (ARM: move signal handlers into a vdso-like page)

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

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

From: Russell King <[email protected]>

commit 8c0cc8a5d90bc7373a7a9e7f7a40eb41f51e03fc upstream.

Olof reports that noMMU builds error out with:

arch/arm/kernel/signal.c: In function 'setup_return':
arch/arm/kernel/signal.c:413:25: error: 'mm_context_t' has no member named 'sigpage'

This shows one of the evilnesses of IS_ENABLED(). Get rid of it here
and replace it with #ifdef's - and as no noMMU platform can make use
of sigpage, depend on CONIFG_MMU not CONFIG_ARM_MPU.

Reported-by: Olof Johansson <[email protected]>
Signed-off-by: Russell King <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/arm/include/asm/elf.h | 2 ++
arch/arm/kernel/signal.c | 5 ++++-
2 files changed, 6 insertions(+), 1 deletion(-)

--- a/arch/arm/include/asm/elf.h
+++ b/arch/arm/include/asm/elf.h
@@ -130,8 +130,10 @@ struct mm_struct;
extern unsigned long arch_randomize_brk(struct mm_struct *mm);
#define arch_randomize_brk arch_randomize_brk

+#ifdef CONFIG_MMU
#define ARCH_HAS_SETUP_ADDITIONAL_PAGES 1
struct linux_binprm;
int arch_setup_additional_pages(struct linux_binprm *, int);
+#endif

#endif
--- a/arch/arm/kernel/signal.c
+++ b/arch/arm/kernel/signal.c
@@ -398,6 +398,7 @@ setup_return(struct pt_regs *regs, struc
__put_user(sigreturn_codes[idx+1], rc+1))
return 1;

+#ifdef CONFIG_MMU
if (cpsr & MODE32_BIT) {
struct mm_struct *mm = current->mm;
/*
@@ -407,7 +408,9 @@ setup_return(struct pt_regs *regs, struc
*/
retcode = mm->context.sigpage + signal_return_offset +
(idx << 2) + thumb;
- } else {
+ } else
+#endif
+ {
/*
* Ensure that the instruction cache sees
* the return code written onto the stack.

2013-08-09 01:58:38

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 012/102] ARM: 7784/1: mm: ensure SMP alternates assemble to exactly 4 bytes with Thumb-2

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

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

From: Will Deacon <[email protected]>

commit bf3f0f332f76a85ff3a0b393aaded5a8533769c0 upstream.

Commit ae8a8b9553bd ("ARM: 7691/1: mm: kill unused TLB_CAN_READ_FROM_L1_CACHE
and use ALT_SMP instead") added early function returns for page table
cache flushing operations on ARMv7 SMP CPUs.

Unfortunately, when targetting Thumb-2, these `mov pc, lr' sequences
assemble to 2 bytes which can lead to corruption of the instruction
stream after code patching.

This patch fixes the alternates to use wide (32-bit) instructions for
Thumb-2, therefore ensuring that the patching code works correctly.

Signed-off-by: Will Deacon <[email protected]>
Signed-off-by: Russell King <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/arm/mm/proc-v7-2level.S | 2 +-
arch/arm/mm/proc-v7-3level.S | 2 +-
arch/arm/mm/proc-v7.S | 11 ++++++-----
3 files changed, 8 insertions(+), 7 deletions(-)

--- a/arch/arm/mm/proc-v7-2level.S
+++ b/arch/arm/mm/proc-v7-2level.S
@@ -110,7 +110,7 @@ ENTRY(cpu_v7_set_pte_ext)
ARM( str r3, [r0, #2048]! )
THUMB( add r0, r0, #2048 )
THUMB( str r3, [r0] )
- ALT_SMP(mov pc,lr)
+ ALT_SMP(W(nop))
ALT_UP (mcr p15, 0, r0, c7, c10, 1) @ flush_pte
#endif
mov pc, lr
--- a/arch/arm/mm/proc-v7-3level.S
+++ b/arch/arm/mm/proc-v7-3level.S
@@ -73,7 +73,7 @@ ENTRY(cpu_v7_set_pte_ext)
tst r3, #1 << (55 - 32) @ L_PTE_DIRTY
orreq r2, #L_PTE_RDONLY
1: strd r2, r3, [r0]
- ALT_SMP(mov pc, lr)
+ ALT_SMP(W(nop))
ALT_UP (mcr p15, 0, r0, c7, c10, 1) @ flush_pte
#endif
mov pc, lr
--- a/arch/arm/mm/proc-v7.S
+++ b/arch/arm/mm/proc-v7.S
@@ -75,13 +75,14 @@ ENTRY(cpu_v7_do_idle)
ENDPROC(cpu_v7_do_idle)

ENTRY(cpu_v7_dcache_clean_area)
- ALT_SMP(mov pc, lr) @ MP extensions imply L1 PTW
- ALT_UP(W(nop))
- dcache_line_size r2, r3
-1: mcr p15, 0, r0, c7, c10, 1 @ clean D entry
+ ALT_SMP(W(nop)) @ MP extensions imply L1 PTW
+ ALT_UP_B(1f)
+ mov pc, lr
+1: dcache_line_size r2, r3
+2: mcr p15, 0, r0, c7, c10, 1 @ clean D entry
add r0, r0, r2
subs r1, r1, r2
- bhi 1b
+ bhi 2b
dsb
mov pc, lr
ENDPROC(cpu_v7_dcache_clean_area)

2013-08-09 01:58:36

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 008/102] ARM: make vectors page inaccessible from userspace

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

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

From: Russell King <[email protected]>

commit a5463cd3435475386cbbe7b06e01292ac169d36f upstream.

If kuser helpers are not provided by the kernel, disable user access to
the vectors page. With the kuser helpers gone, there is no reason for
this page to be visible to userspace.

Signed-off-by: Russell King <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/arm/include/asm/page.h | 2 ++
arch/arm/kernel/process.c | 7 ++++++-
arch/arm/mm/mmu.c | 4 ++++
3 files changed, 12 insertions(+), 1 deletion(-)

--- a/arch/arm/include/asm/page.h
+++ b/arch/arm/include/asm/page.h
@@ -142,7 +142,9 @@ extern void __cpu_copy_user_highpage(str
#define clear_page(page) memset((void *)(page), 0, PAGE_SIZE)
extern void copy_page(void *to, const void *from);

+#ifdef CONFIG_KUSER_HELPERS
#define __HAVE_ARCH_GATE_AREA 1
+#endif

#ifdef CONFIG_ARM_LPAE
#include <asm/pgtable-3level-types.h>
--- a/arch/arm/kernel/process.c
+++ b/arch/arm/kernel/process.c
@@ -433,6 +433,7 @@ unsigned long arch_randomize_brk(struct
}

#ifdef CONFIG_MMU
+#ifdef CONFIG_KUSER_HELPERS
/*
* The vectors page is always readable from user space for the
* atomic helpers. Insert it into the gate_vma so that it is visible
@@ -465,10 +466,14 @@ int in_gate_area_no_mm(unsigned long add
{
return in_gate_area(NULL, addr);
}
+#define is_gate_vma(vma) ((vma) = &gate_vma)
+#else
+#define is_gate_vma(vma) 0
+#endif

const char *arch_vma_name(struct vm_area_struct *vma)
{
- return (vma == &gate_vma) ? "[vectors]" :
+ return is_gate_vma(vma) ? "[vectors]" :
(vma->vm_mm && vma->vm_start == vma->vm_mm->context.sigpage) ?
"[sigpage]" : NULL;
}
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -1220,7 +1220,11 @@ static void __init devicemaps_init(struc
map.pfn = __phys_to_pfn(virt_to_phys(vectors));
map.virtual = 0xffff0000;
map.length = PAGE_SIZE;
+#ifdef CONFIG_KUSER_HELPERS
map.type = MT_HIGH_VECTORS;
+#else
+ map.type = MT_LOW_VECTORS;
+#endif
create_mapping(&map);

if (!vectors_high()) {

2013-08-09 01:58:46

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 026/102] USB: mos7840: fix race in register handling

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

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

From: Johan Hovold <[email protected]>

commit d8a083cc746664916d9d36ed9e4d08a29525f245 upstream.

Fix race in mos7840_get_reg which unconditionally manipulated the
control urb (which may already be in use) by adding a control-urb busy
flag.

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

---
drivers/usb/serial/mos7840.c | 18 ++++++++++++++++--
1 file changed, 16 insertions(+), 2 deletions(-)

--- a/drivers/usb/serial/mos7840.c
+++ b/drivers/usb/serial/mos7840.c
@@ -183,6 +183,10 @@
#define LED_ON_MS 500
#define LED_OFF_MS 500

+enum mos7840_flag {
+ MOS7840_FLAG_CTRL_BUSY,
+};
+
static int device_type;

static const struct usb_device_id id_table[] = {
@@ -241,6 +245,8 @@ struct moschip_port {
bool led_flag;
struct timer_list led_timer1; /* Timer for LED on */
struct timer_list led_timer2; /* Timer for LED off */
+
+ unsigned long flags;
};

/*
@@ -467,10 +473,10 @@ static void mos7840_control_callback(str
case -ESHUTDOWN:
/* this urb is terminated, clean up */
dev_dbg(dev, "%s - urb shutting down with status: %d\n", __func__, status);
- return;
+ goto out;
default:
dev_dbg(dev, "%s - nonzero urb status received: %d\n", __func__, status);
- return;
+ goto out;
}

dev_dbg(dev, "%s urb buffer size is %d\n", __func__, urb->actual_length);
@@ -483,6 +489,8 @@ static void mos7840_control_callback(str
mos7840_handle_new_msr(mos7840_port, regval);
else if (mos7840_port->MsrLsr == 1)
mos7840_handle_new_lsr(mos7840_port, regval);
+out:
+ clear_bit_unlock(MOS7840_FLAG_CTRL_BUSY, &mos7840_port->flags);
}

static int mos7840_get_reg(struct moschip_port *mcs, __u16 Wval, __u16 reg,
@@ -493,6 +501,9 @@ static int mos7840_get_reg(struct moschi
unsigned char *buffer = mcs->ctrl_buf;
int ret;

+ if (test_and_set_bit_lock(MOS7840_FLAG_CTRL_BUSY, &mcs->flags))
+ return -EBUSY;
+
dr->bRequestType = MCS_RD_RTYPE;
dr->bRequest = MCS_RDREQ;
dr->wValue = cpu_to_le16(Wval); /* 0 */
@@ -504,6 +515,9 @@ static int mos7840_get_reg(struct moschi
mos7840_control_callback, mcs);
mcs->control_urb->transfer_buffer_length = 2;
ret = usb_submit_urb(mcs->control_urb, GFP_ATOMIC);
+ if (ret)
+ clear_bit_unlock(MOS7840_FLAG_CTRL_BUSY, &mcs->flags);
+
return ret;
}


2013-08-09 01:58:53

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 030/102] iwlwifi: mvm: fix L2P BA ressources leak

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

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

From: Emmanuel Grumbach <[email protected]>

commit 93a426673fbfeae7fa6b27008828e2ac4c08dbee upstream.

We didn't release the Rx AMPDU ressources properly.
This bug led to firmware assert after 16 BA sessions.

Signed-off-by: Emmanuel Grumbach <[email protected]>
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/net/wireless/iwlwifi/mvm/sta.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)

--- a/drivers/net/wireless/iwlwifi/mvm/sta.c
+++ b/drivers/net/wireless/iwlwifi/mvm/sta.c
@@ -621,8 +621,12 @@ int iwl_mvm_sta_rx_agg(struct iwl_mvm *m
cmd.mac_id_n_color = cpu_to_le32(mvm_sta->mac_id_n_color);
cmd.sta_id = mvm_sta->sta_id;
cmd.add_modify = STA_MODE_MODIFY;
- cmd.add_immediate_ba_tid = (u8) tid;
- cmd.add_immediate_ba_ssn = cpu_to_le16(ssn);
+ if (start) {
+ cmd.add_immediate_ba_tid = (u8) tid;
+ cmd.add_immediate_ba_ssn = cpu_to_le16(ssn);
+ } else {
+ cmd.remove_immediate_ba_tid = (u8) tid;
+ }
cmd.modify_mask = start ? STA_MODIFY_ADD_BA_TID :
STA_MODIFY_REMOVE_BA_TID;


2013-08-09 01:59:14

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 053/102] svcrpc: fix gss-proxy xdr decoding oops

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

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

From: "J. Bruce Fields" <[email protected]>

commit dc43376c26cef74226174a2394f37f2a3f8a8639 upstream.

Uninitialized stack data was being used as the destination for memcpy's.

Longer term we'll just delete some of this code; all we're doing is
skipping over xdr that we don't care about.

Signed-off-by: J. Bruce Fields <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
net/sunrpc/auth_gss/gss_rpc_xdr.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)

--- a/net/sunrpc/auth_gss/gss_rpc_xdr.c
+++ b/net/sunrpc/auth_gss/gss_rpc_xdr.c
@@ -430,7 +430,7 @@ static int dummy_enc_nameattr_array(stru
static int dummy_dec_nameattr_array(struct xdr_stream *xdr,
struct gssx_name_attr_array *naa)
{
- struct gssx_name_attr dummy;
+ struct gssx_name_attr dummy = { .attr = {.len = 0} };
u32 count, i;
__be32 *p;

@@ -493,12 +493,13 @@ static int gssx_enc_name(struct xdr_stre
return err;
}

+
static int gssx_dec_name(struct xdr_stream *xdr,
struct gssx_name *name)
{
- struct xdr_netobj dummy_netobj;
- struct gssx_name_attr_array dummy_name_attr_array;
- struct gssx_option_array dummy_option_array;
+ struct xdr_netobj dummy_netobj = { .len = 0 };
+ struct gssx_name_attr_array dummy_name_attr_array = { .count = 0 };
+ struct gssx_option_array dummy_option_array = { .count = 0 };
int err;

/* name->display_name */

2013-08-09 01:59:20

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 064/102] zram: avoid access beyond the zram device

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

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

From: Jiang Liu <[email protected]>

commit 12a7ad3b810e77137d0caf97a6dd97591e075b30 upstream.

Function valid_io_request() should verify the entire request are within
the zram device address range. Otherwise it may cause invalid memory
access when accessing/modifying zram->meta->table[index] because the
'index' is out of range. Then it may access non-exist memory, randomly
modify memory belong to other subsystems, which is hard to track down.

Signed-off-by: Jiang Liu <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/staging/zram/zram_drv.c | 17 ++++++++++++-----
1 file changed, 12 insertions(+), 5 deletions(-)

--- a/drivers/staging/zram/zram_drv.c
+++ b/drivers/staging/zram/zram_drv.c
@@ -420,13 +420,20 @@ out:
*/
static inline int valid_io_request(struct zram *zram, struct bio *bio)
{
- if (unlikely(
- (bio->bi_sector >= (zram->disksize >> SECTOR_SHIFT)) ||
- (bio->bi_sector & (ZRAM_SECTOR_PER_LOGICAL_BLOCK - 1)) ||
- (bio->bi_size & (ZRAM_LOGICAL_BLOCK_SIZE - 1)))) {
+ u64 start, end, bound;
+
+ /* unaligned request */
+ if (unlikely(bio->bi_sector & (ZRAM_SECTOR_PER_LOGICAL_BLOCK - 1)))
+ return 0;
+ if (unlikely(bio->bi_size & (ZRAM_LOGICAL_BLOCK_SIZE - 1)))
+ return 0;

+ start = bio->bi_sector;
+ end = start + (bio->bi_size >> SECTOR_SHIFT);
+ bound = zram->disksize >> SECTOR_SHIFT;
+ /* out of range range */
+ if (unlikely(start >= bound || end >= bound || start > end))
return 0;
- }

/* I/O request is valid */
return 1;

2013-08-09 01:59:29

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 071/102] PCI: Retry allocation of only the resource type that failed

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

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

From: Yinghai Lu <[email protected]>

commit aa914f5ec25e4371ba18b312971314be1b9b1076 upstream.

Ben Herrenschmidt reported the following problem:

- The bus has space for all desired MMIO resources, including optional
space for SR-IOV devices
- We attempt to allocate I/O port space, but it fails because the bus
has no I/O space
- Because of the I/O allocation failure, we retry MMIO allocation,
requesting only the required space, without the optional SR-IOV space

This means we don't allocate the optional SR-IOV space, even though we
could.

This is related to 0c5be0cb0e ("PCI: Retry on IORESOURCE_IO type
allocations").

This patch changes how we handle allocation failures. We will now retry
allocation of only the resource type that failed. If MMIO allocation
fails, we'll retry only MMIO allocation. If I/O port allocation fails,
we'll retry only I/O port allocation.

[bhelgaas: changelog]
Reference: https://lkml.kernel.org/r/1367712653.11982.19.camel@pasglop
Reported-by: Benjamin Herrenschmidt <[email protected]>
Tested-by: Gavin Shan <[email protected]>
Signed-off-by: Yinghai Lu <[email protected]>
Signed-off-by: Bjorn Helgaas <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/pci/setup-bus.c | 69 +++++++++++++++++++++++++++++++++++++++++++++++-
1 file changed, 68 insertions(+), 1 deletion(-)

--- a/drivers/pci/setup-bus.c
+++ b/drivers/pci/setup-bus.c
@@ -300,6 +300,47 @@ static void assign_requested_resources_s
}
}

+static unsigned long pci_fail_res_type_mask(struct list_head *fail_head)
+{
+ struct pci_dev_resource *fail_res;
+ unsigned long mask = 0;
+
+ /* check failed type */
+ list_for_each_entry(fail_res, fail_head, list)
+ mask |= fail_res->flags;
+
+ /*
+ * one pref failed resource will set IORESOURCE_MEM,
+ * as we can allocate pref in non-pref range.
+ * Will release all assigned non-pref sibling resources
+ * according to that bit.
+ */
+ return mask & (IORESOURCE_IO | IORESOURCE_MEM | IORESOURCE_PREFETCH);
+}
+
+static bool pci_need_to_release(unsigned long mask, struct resource *res)
+{
+ if (res->flags & IORESOURCE_IO)
+ return !!(mask & IORESOURCE_IO);
+
+ /* check pref at first */
+ if (res->flags & IORESOURCE_PREFETCH) {
+ if (mask & IORESOURCE_PREFETCH)
+ return true;
+ /* count pref if its parent is non-pref */
+ else if ((mask & IORESOURCE_MEM) &&
+ !(res->parent->flags & IORESOURCE_PREFETCH))
+ return true;
+ else
+ return false;
+ }
+
+ if (res->flags & IORESOURCE_MEM)
+ return !!(mask & IORESOURCE_MEM);
+
+ return false; /* should not get here */
+}
+
static void __assign_resources_sorted(struct list_head *head,
struct list_head *realloc_head,
struct list_head *fail_head)
@@ -312,11 +353,24 @@ static void __assign_resources_sorted(st
* if could do that, could get out early.
* if could not do that, we still try to assign requested at first,
* then try to reassign add_size for some resources.
+ *
+ * Separate three resource type checking if we need to release
+ * assigned resource after requested + add_size try.
+ * 1. if there is io port assign fail, will release assigned
+ * io port.
+ * 2. if there is pref mmio assign fail, release assigned
+ * pref mmio.
+ * if assigned pref mmio's parent is non-pref mmio and there
+ * is non-pref mmio assign fail, will release that assigned
+ * pref mmio.
+ * 3. if there is non-pref mmio assign fail or pref mmio
+ * assigned fail, will release assigned non-pref mmio.
*/
LIST_HEAD(save_head);
LIST_HEAD(local_fail_head);
struct pci_dev_resource *save_res;
- struct pci_dev_resource *dev_res;
+ struct pci_dev_resource *dev_res, *tmp_res;
+ unsigned long fail_type;

/* Check if optional add_size is there */
if (!realloc_head || list_empty(realloc_head))
@@ -348,6 +402,19 @@ static void __assign_resources_sorted(st
return;
}

+ /* check failed type */
+ fail_type = pci_fail_res_type_mask(&local_fail_head);
+ /* remove not need to be released assigned res from head list etc */
+ list_for_each_entry_safe(dev_res, tmp_res, head, list)
+ if (dev_res->res->parent &&
+ !pci_need_to_release(fail_type, dev_res->res)) {
+ /* remove it from realloc_head list */
+ remove_from_list(realloc_head, dev_res->res);
+ remove_from_list(&save_head, dev_res->res);
+ list_del(&dev_res->list);
+ kfree(dev_res);
+ }
+
free_list(&local_fail_head);
/* Release assigned resource */
list_for_each_entry(dev_res, head, list)

2013-08-09 01:59:32

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 082/102] s390/bitops: fix find_next_bit_left

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

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

From: Martin Schwidefsky <[email protected]>

commit 3b0040a47ad63f7147e9e7d2febb61a3b564bb90 upstream.

The find_next_bit_left function is broken if used with an offset which
is not a multiple of 64. The shift to mask the bits of a 64-bit word
not to search is in the wrong direction, the result can be either a
bit found smaller than the offset or failure to find a set bit.

Signed-off-by: Martin Schwidefsky <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/s390/include/asm/bitops.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/arch/s390/include/asm/bitops.h
+++ b/arch/s390/include/asm/bitops.h
@@ -693,7 +693,7 @@ static inline int find_next_bit_left(con
size -= offset;
p = addr + offset / BITS_PER_LONG;
if (bit) {
- set = __flo_word(0, *p & (~0UL << bit));
+ set = __flo_word(0, *p & (~0UL >> bit));
if (set >= size)
return size + offset;
if (set < BITS_PER_LONG)

2013-08-09 01:59:45

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 097/102] ndisc: Add missing inline to ndisc_addr_option_pad

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

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

From: Joe Perches <[email protected]>

[ Upstream commit d9d10a30964504af834d8d250a0c76d4ae91eb1e ]

Signed-off-by: Joe Perches <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
include/net/ndisc.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/include/net/ndisc.h
+++ b/include/net/ndisc.h
@@ -119,7 +119,7 @@ extern struct ndisc_options *ndisc_parse
* if RFC 3831 IPv6-over-Fibre Channel is ever implemented it may
* also need a pad of 2.
*/
-static int ndisc_addr_option_pad(unsigned short type)
+static inline int ndisc_addr_option_pad(unsigned short type)
{
switch (type) {
case ARPHRD_INFINIBAND: return 2;

2013-08-09 01:59:50

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 101/102] iwlwifi: mvm: set SSID bits for passive channels

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

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

From: David Spinadel <[email protected]>

commit bb963c4a43eb5127eb0bbfa16c7a6a209b0af5db upstream.

Set SSID bitmap for direct scan even on passive channels,
for the passive-to-active feature. Without this patch only
the SSID from probe request template is sent on passive
channels, after passive-to-active switching, causing us to
not find all desired networks.

Remove the unused passive scan mask constant.

Reviewed-by: Emmanuel Grumbach <[email protected]>
Signed-off-by: David Spinadel <[email protected]>
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>


---
drivers/net/wireless/iwlwifi/mvm/fw-api-scan.h | 1 -
drivers/net/wireless/iwlwifi/mvm/scan.c | 11 ++---------
2 files changed, 2 insertions(+), 10 deletions(-)

--- a/drivers/net/wireless/iwlwifi/mvm/fw-api-scan.h
+++ b/drivers/net/wireless/iwlwifi/mvm/fw-api-scan.h
@@ -69,7 +69,6 @@
/* Scan Commands, Responses, Notifications */

/* Masks for iwl_scan_channel.type flags */
-#define SCAN_CHANNEL_TYPE_PASSIVE 0
#define SCAN_CHANNEL_TYPE_ACTIVE BIT(0)
#define SCAN_CHANNEL_NARROW_BAND BIT(22)

--- a/drivers/net/wireless/iwlwifi/mvm/scan.c
+++ b/drivers/net/wireless/iwlwifi/mvm/scan.c
@@ -176,19 +176,12 @@ static void iwl_mvm_scan_fill_channels(s
struct iwl_scan_channel *chan = (struct iwl_scan_channel *)
(cmd->data + le16_to_cpu(cmd->tx_cmd.len));
int i;
- __le32 chan_type_value;
-
- if (req->n_ssids > 0)
- chan_type_value = cpu_to_le32(BIT(req->n_ssids + 1) - 1);
- else
- chan_type_value = SCAN_CHANNEL_TYPE_PASSIVE;

for (i = 0; i < cmd->channel_count; i++) {
chan->channel = cpu_to_le16(req->channels[i]->hw_value);
+ chan->type = cpu_to_le32(BIT(req->n_ssids) - 1);
if (req->channels[i]->flags & IEEE80211_CHAN_PASSIVE_SCAN)
- chan->type = SCAN_CHANNEL_TYPE_PASSIVE;
- else
- chan->type = chan_type_value;
+ chan->type &= cpu_to_le32(~SCAN_CHANNEL_TYPE_ACTIVE);
chan->active_dwell = cpu_to_le16(active_dwell);
chan->passive_dwell = cpu_to_le16(passive_dwell);
chan->iteration_count = cpu_to_le16(1);

2013-08-09 01:59:54

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 092/102] genetlink: release cb_lock before requesting additional module

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

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

From: Stanislaw Gruszka <[email protected]>

[ Upstream commit c74f2b2678f40b80265dd53556f1f778c8e1823f ]

Requesting external module with cb_lock taken can result in
the deadlock like showed below:

[ 2458.111347] Showing all locks held in the system:
[ 2458.111347] 1 lock held by NetworkManager/582:
[ 2458.111347] #0: (cb_lock){++++++}, at: [<ffffffff8162bc79>] genl_rcv+0x19/0x40
[ 2458.111347] 1 lock held by modprobe/603:
[ 2458.111347] #0: (cb_lock){++++++}, at: [<ffffffff8162baa5>] genl_lock_all+0x15/0x30

[ 2461.579457] SysRq : Show Blocked State
[ 2461.580103] task PC stack pid father
[ 2461.580103] NetworkManager D ffff880034b84500 4040 582 1 0x00000080
[ 2461.580103] ffff8800197ff720 0000000000000046 00000000001d5340 ffff8800197fffd8
[ 2461.580103] ffff8800197fffd8 00000000001d5340 ffff880019631700 7fffffffffffffff
[ 2461.580103] ffff8800197ff880 ffff8800197ff878 ffff880019631700 ffff880019631700
[ 2461.580103] Call Trace:
[ 2461.580103] [<ffffffff817355f9>] schedule+0x29/0x70
[ 2461.580103] [<ffffffff81731ad1>] schedule_timeout+0x1c1/0x360
[ 2461.580103] [<ffffffff810e69eb>] ? mark_held_locks+0xbb/0x140
[ 2461.580103] [<ffffffff817377ac>] ? _raw_spin_unlock_irq+0x2c/0x50
[ 2461.580103] [<ffffffff810e6b6d>] ? trace_hardirqs_on_caller+0xfd/0x1c0
[ 2461.580103] [<ffffffff81736398>] wait_for_completion_killable+0xe8/0x170
[ 2461.580103] [<ffffffff810b7fa0>] ? wake_up_state+0x20/0x20
[ 2461.580103] [<ffffffff81095825>] call_usermodehelper_exec+0x1a5/0x210
[ 2461.580103] [<ffffffff817362ed>] ? wait_for_completion_killable+0x3d/0x170
[ 2461.580103] [<ffffffff81095cc3>] __request_module+0x1b3/0x370
[ 2461.580103] [<ffffffff810e6b6d>] ? trace_hardirqs_on_caller+0xfd/0x1c0
[ 2461.580103] [<ffffffff8162c5c9>] ctrl_getfamily+0x159/0x190
[ 2461.580103] [<ffffffff8162d8a4>] genl_family_rcv_msg+0x1f4/0x2e0
[ 2461.580103] [<ffffffff8162d990>] ? genl_family_rcv_msg+0x2e0/0x2e0
[ 2461.580103] [<ffffffff8162da1e>] genl_rcv_msg+0x8e/0xd0
[ 2461.580103] [<ffffffff8162b729>] netlink_rcv_skb+0xa9/0xc0
[ 2461.580103] [<ffffffff8162bc88>] genl_rcv+0x28/0x40
[ 2461.580103] [<ffffffff8162ad6d>] netlink_unicast+0xdd/0x190
[ 2461.580103] [<ffffffff8162b149>] netlink_sendmsg+0x329/0x750
[ 2461.580103] [<ffffffff815db849>] sock_sendmsg+0x99/0xd0
[ 2461.580103] [<ffffffff810bb58f>] ? local_clock+0x5f/0x70
[ 2461.580103] [<ffffffff810e96e8>] ? lock_release_non_nested+0x308/0x350
[ 2461.580103] [<ffffffff815dbc6e>] ___sys_sendmsg+0x39e/0x3b0
[ 2461.580103] [<ffffffff810565af>] ? kvm_clock_read+0x2f/0x50
[ 2461.580103] [<ffffffff810218b9>] ? sched_clock+0x9/0x10
[ 2461.580103] [<ffffffff810bb2bd>] ? sched_clock_local+0x1d/0x80
[ 2461.580103] [<ffffffff810bb448>] ? sched_clock_cpu+0xa8/0x100
[ 2461.580103] [<ffffffff810e33ad>] ? trace_hardirqs_off+0xd/0x10
[ 2461.580103] [<ffffffff810bb58f>] ? local_clock+0x5f/0x70
[ 2461.580103] [<ffffffff810e3f7f>] ? lock_release_holdtime.part.28+0xf/0x1a0
[ 2461.580103] [<ffffffff8120fec9>] ? fget_light+0xf9/0x510
[ 2461.580103] [<ffffffff8120fe0c>] ? fget_light+0x3c/0x510
[ 2461.580103] [<ffffffff815dd1d2>] __sys_sendmsg+0x42/0x80
[ 2461.580103] [<ffffffff815dd222>] SyS_sendmsg+0x12/0x20
[ 2461.580103] [<ffffffff81741ad9>] system_call_fastpath+0x16/0x1b
[ 2461.580103] modprobe D ffff88000f2c8000 4632 603 602 0x00000080
[ 2461.580103] ffff88000f04fba8 0000000000000046 00000000001d5340 ffff88000f04ffd8
[ 2461.580103] ffff88000f04ffd8 00000000001d5340 ffff8800377d4500 ffff8800377d4500
[ 2461.580103] ffffffff81d0b260 ffffffff81d0b268 ffffffff00000000 ffffffff81d0b2b0
[ 2461.580103] Call Trace:
[ 2461.580103] [<ffffffff817355f9>] schedule+0x29/0x70
[ 2461.580103] [<ffffffff81736d4d>] rwsem_down_write_failed+0xed/0x1a0
[ 2461.580103] [<ffffffff810bb200>] ? update_cpu_load_active+0x10/0xb0
[ 2461.580103] [<ffffffff8137b473>] call_rwsem_down_write_failed+0x13/0x20
[ 2461.580103] [<ffffffff8173492d>] ? down_write+0x9d/0xb2
[ 2461.580103] [<ffffffff8162baa5>] ? genl_lock_all+0x15/0x30
[ 2461.580103] [<ffffffff8162baa5>] genl_lock_all+0x15/0x30
[ 2461.580103] [<ffffffff8162cbb3>] genl_register_family+0x53/0x1f0
[ 2461.580103] [<ffffffffa01dc000>] ? 0xffffffffa01dbfff
[ 2461.580103] [<ffffffff8162d650>] genl_register_family_with_ops+0x20/0x80
[ 2461.580103] [<ffffffffa01dc000>] ? 0xffffffffa01dbfff
[ 2461.580103] [<ffffffffa017fe84>] nl80211_init+0x24/0xf0 [cfg80211]
[ 2461.580103] [<ffffffffa01dc000>] ? 0xffffffffa01dbfff
[ 2461.580103] [<ffffffffa01dc043>] cfg80211_init+0x43/0xdb [cfg80211]
[ 2461.580103] [<ffffffff810020fa>] do_one_initcall+0xfa/0x1b0
[ 2461.580103] [<ffffffff8105cb93>] ? set_memory_nx+0x43/0x50
[ 2461.580103] [<ffffffff810f75af>] load_module+0x1c6f/0x27f0
[ 2461.580103] [<ffffffff810f2c90>] ? store_uevent+0x40/0x40
[ 2461.580103] [<ffffffff810f82c6>] SyS_finit_module+0x86/0xb0
[ 2461.580103] [<ffffffff81741ad9>] system_call_fastpath+0x16/0x1b
[ 2461.580103] Sched Debug Version: v0.10, 3.11.0-0.rc1.git4.1.fc20.x86_64 #1

Problem start to happen after adding net-pf-16-proto-16-family-nl80211
alias name to cfg80211 module by below commit (though that commit
itself is perfectly fine):

commit fb4e156886ce6e8309e912d8b370d192330d19d3
Author: Marcel Holtmann <[email protected]>
Date: Sun Apr 28 16:22:06 2013 -0700

nl80211: Add generic netlink module alias for cfg80211/nl80211

Reported-and-tested-by: Jeff Layton <[email protected]>
Reported-by: Richard W.M. Jones <[email protected]>
Signed-off-by: Stanislaw Gruszka <[email protected]>
Reviewed-by: Pravin B Shelar <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/netlink/genetlink.c | 2 ++
1 file changed, 2 insertions(+)

--- a/net/netlink/genetlink.c
+++ b/net/netlink/genetlink.c
@@ -877,8 +877,10 @@ static int ctrl_getfamily(struct sk_buff
#ifdef CONFIG_MODULES
if (res == NULL) {
genl_unlock();
+ up_read(&cb_lock);
request_module("net-pf-%d-proto-%d-family-%s",
PF_NETLINK, NETLINK_GENERIC, name);
+ down_read(&cb_lock);
genl_lock();
res = genl_family_find_byname(name);
}

2013-08-09 01:59:52

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 102/102] iwlwifi: dvm: dont send BT_CONFIG on devices w/o Bluetooth

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

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

From: Johannes Berg <[email protected]>

commit 707aee401d2467baa785a697f40a6e2d9ee79ad5 upstream.

The BT_CONFIG command that is sent to the device during
startup will enable BT coex unless the module parameter
turns it off, but on devices without Bluetooth this may
cause problems, as reported in Redhat BZ 885407.

Fix this by sending the BT_CONFIG command only when the
device has Bluetooth.

Reviewed-by: Emmanuel Grumbach <[email protected]>
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>


---
drivers/net/wireless/iwlwifi/dvm/main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/net/wireless/iwlwifi/dvm/main.c
+++ b/drivers/net/wireless/iwlwifi/dvm/main.c
@@ -758,7 +758,7 @@ int iwl_alive_start(struct iwl_priv *pri
BT_COEX_PRIO_TBL_EVT_INIT_CALIB2);
if (ret)
return ret;
- } else {
+ } else if (priv->cfg->bt_params) {
/*
* default is 2-wire BT coexexistence support
*/

2013-08-09 02:00:47

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 100/102] net/mlx4_core: VFs must ignore the enable_64b_cqe_eqe module param

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

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

From: Jack Morgenstein <[email protected]>

[ Upstream commit b30513202c6c14120f70b2e9aa1e97d47bbc2313 ]

Slaves get the 64B CQE/EQE state from QUERY_HCA, not from the module parameter.

If the parameter is set to zero, the slave outputs an incorrect/irrelevant
warning message that 64B CQEs/EQEs are supported but not enabled (even if the
hypervisor has enabled 64B CQEs/EQEs).

Signed-off-by: Jack Morgenstein <[email protected]>
Signed-off-by: Or Gerlitz <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/ethernet/mellanox/mlx4/main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/net/ethernet/mellanox/mlx4/main.c
+++ b/drivers/net/ethernet/mellanox/mlx4/main.c
@@ -371,7 +371,7 @@ static int mlx4_dev_cap(struct mlx4_dev

dev->caps.sqp_demux = (mlx4_is_master(dev)) ? MLX4_MAX_NUM_SLAVES : 0;

- if (!enable_64b_cqe_eqe) {
+ if (!enable_64b_cqe_eqe && !mlx4_is_slave(dev)) {
if (dev_cap->flags &
(MLX4_DEV_CAP_FLAG_64B_CQE | MLX4_DEV_CAP_FLAG_64B_EQE)) {
mlx4_warn(dev, "64B EQEs/CQEs supported by the device but not enabled\n");

2013-08-09 02:01:06

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 099/102] net/mlx4_core: Dont give VFs MAC addresses which are derived from the PF MAC

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

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

From: Or Gerlitz <[email protected]>

[ Upstream commit 0508ad646836007e6e6b62331eee7356844eac3d ]

If the user has not assigned a MAC address to a VM, then don't give it MAC which
is based on the PF one. The current derivation scheme is wrong and leads to VM
MAC collisions when the number of cards/hypervisors becomes big enough.

Instead, just give it zeros and let them figure out what to do with that.

Signed-off-by: Or Gerlitz <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/ethernet/mellanox/mlx4/fw.c | 11 +----------
1 file changed, 1 insertion(+), 10 deletions(-)

--- a/drivers/net/ethernet/mellanox/mlx4/fw.c
+++ b/drivers/net/ethernet/mellanox/mlx4/fw.c
@@ -840,16 +840,7 @@ int mlx4_QUERY_PORT_wrapper(struct mlx4_
MLX4_CMD_NATIVE);

if (!err && dev->caps.function != slave) {
- /* if config MAC in DB use it */
- if (priv->mfunc.master.vf_oper[slave].vport[vhcr->in_modifier].state.mac)
- def_mac = priv->mfunc.master.vf_oper[slave].vport[vhcr->in_modifier].state.mac;
- else {
- /* set slave default_mac address */
- MLX4_GET(def_mac, outbox->buf, QUERY_PORT_MAC_OFFSET);
- def_mac += slave << 8;
- priv->mfunc.master.vf_admin[slave].vport[vhcr->in_modifier].mac = def_mac;
- }
-
+ def_mac = priv->mfunc.master.vf_oper[slave].vport[vhcr->in_modifier].state.mac;
MLX4_PUT(outbox->buf, def_mac, QUERY_PORT_MAC_OFFSET);

/* get port type - currently only eth is enabled */

2013-08-09 01:59:42

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 093/102] net_sched: Fix stack info leak in cbq_dump_wrr().

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

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

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

[ Upstream commit a0db856a95a29efb1c23db55c02d9f0ff4f0db48 ]

Make sure the reserved fields, and padding (if any), are
fully initialized.

Based upon a patch by Dan Carpenter and feedback from
Joe Perches.

Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/sched/sch_cbq.c | 1 +
1 file changed, 1 insertion(+)

--- a/net/sched/sch_cbq.c
+++ b/net/sched/sch_cbq.c
@@ -1465,6 +1465,7 @@ static int cbq_dump_wrr(struct sk_buff *
unsigned char *b = skb_tail_pointer(skb);
struct tc_cbq_wrropt opt;

+ memset(&opt, 0, sizeof(opt));
opt.flags = 0;
opt.allot = cl->allot;
opt.priority = cl->priority + 1;

2013-08-09 02:01:28

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 098/102] 8139cp: Add dma_mapping_error checking

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

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

From: Neil Horman <[email protected]>

[ Upstream commit cf3c4c03060b688cbc389ebc5065ebcce5653e96 ]

Self explanitory dma_mapping_error addition to the 8139 driver, based on this:
https://bugzilla.redhat.com/show_bug.cgi?id=947250

It showed several backtraces arising for dma_map_* usage without checking the
return code on the mapping. Add the check and abort the rx/tx operation if its
failed. Untested as I have no hardware and the reporter has wandered off, but
seems pretty straightforward.

Signed-off-by: Neil Horman <[email protected]>
CC: "David S. Miller" <[email protected]>
CC: Francois Romieu <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/ethernet/realtek/8139cp.c | 48 +++++++++++++++++++++++++++++++---
1 file changed, 45 insertions(+), 3 deletions(-)

--- a/drivers/net/ethernet/realtek/8139cp.c
+++ b/drivers/net/ethernet/realtek/8139cp.c
@@ -478,7 +478,7 @@ rx_status_loop:

while (1) {
u32 status, len;
- dma_addr_t mapping;
+ dma_addr_t mapping, new_mapping;
struct sk_buff *skb, *new_skb;
struct cp_desc *desc;
const unsigned buflen = cp->rx_buf_sz;
@@ -520,6 +520,13 @@ rx_status_loop:
goto rx_next;
}

+ new_mapping = dma_map_single(&cp->pdev->dev, new_skb->data, buflen,
+ PCI_DMA_FROMDEVICE);
+ if (dma_mapping_error(&cp->pdev->dev, new_mapping)) {
+ dev->stats.rx_dropped++;
+ goto rx_next;
+ }
+
dma_unmap_single(&cp->pdev->dev, mapping,
buflen, PCI_DMA_FROMDEVICE);

@@ -531,12 +538,11 @@ rx_status_loop:

skb_put(skb, len);

- mapping = dma_map_single(&cp->pdev->dev, new_skb->data, buflen,
- PCI_DMA_FROMDEVICE);
cp->rx_skb[rx_tail] = new_skb;

cp_rx_skb(cp, skb, desc);
rx++;
+ mapping = new_mapping;

rx_next:
cp->rx_ring[rx_tail].opts2 = 0;
@@ -716,6 +722,22 @@ static inline u32 cp_tx_vlan_tag(struct
TxVlanTag | swab16(vlan_tx_tag_get(skb)) : 0x00;
}

+static void unwind_tx_frag_mapping(struct cp_private *cp, struct sk_buff *skb,
+ int first, int entry_last)
+{
+ int frag, index;
+ struct cp_desc *txd;
+ skb_frag_t *this_frag;
+ for (frag = 0; frag+first < entry_last; frag++) {
+ index = first+frag;
+ cp->tx_skb[index] = NULL;
+ txd = &cp->tx_ring[index];
+ this_frag = &skb_shinfo(skb)->frags[frag];
+ dma_unmap_single(&cp->pdev->dev, le64_to_cpu(txd->addr),
+ skb_frag_size(this_frag), PCI_DMA_TODEVICE);
+ }
+}
+
static netdev_tx_t cp_start_xmit (struct sk_buff *skb,
struct net_device *dev)
{
@@ -749,6 +771,9 @@ static netdev_tx_t cp_start_xmit (struct

len = skb->len;
mapping = dma_map_single(&cp->pdev->dev, skb->data, len, PCI_DMA_TODEVICE);
+ if (dma_mapping_error(&cp->pdev->dev, mapping))
+ goto out_dma_error;
+
txd->opts2 = opts2;
txd->addr = cpu_to_le64(mapping);
wmb();
@@ -786,6 +811,9 @@ static netdev_tx_t cp_start_xmit (struct
first_len = skb_headlen(skb);
first_mapping = dma_map_single(&cp->pdev->dev, skb->data,
first_len, PCI_DMA_TODEVICE);
+ if (dma_mapping_error(&cp->pdev->dev, first_mapping))
+ goto out_dma_error;
+
cp->tx_skb[entry] = skb;
entry = NEXT_TX(entry);

@@ -799,6 +827,11 @@ static netdev_tx_t cp_start_xmit (struct
mapping = dma_map_single(&cp->pdev->dev,
skb_frag_address(this_frag),
len, PCI_DMA_TODEVICE);
+ if (dma_mapping_error(&cp->pdev->dev, mapping)) {
+ unwind_tx_frag_mapping(cp, skb, first_entry, entry);
+ goto out_dma_error;
+ }
+
eor = (entry == (CP_TX_RING_SIZE - 1)) ? RingEnd : 0;

ctrl = eor | len | DescOwn;
@@ -859,11 +892,16 @@ static netdev_tx_t cp_start_xmit (struct
if (TX_BUFFS_AVAIL(cp) <= (MAX_SKB_FRAGS + 1))
netif_stop_queue(dev);

+out_unlock:
spin_unlock_irqrestore(&cp->lock, intr_flags);

cpw8(TxPoll, NormalTxPoll);

return NETDEV_TX_OK;
+out_dma_error:
+ kfree_skb(skb);
+ cp->dev->stats.tx_dropped++;
+ goto out_unlock;
}

/* Set or clear the multicast filter for this adaptor.
@@ -1054,6 +1092,10 @@ static int cp_refill_rx(struct cp_privat

mapping = dma_map_single(&cp->pdev->dev, skb->data,
cp->rx_buf_sz, PCI_DMA_FROMDEVICE);
+ if (dma_mapping_error(&cp->pdev->dev, mapping)) {
+ kfree_skb(skb);
+ goto err_out;
+ }
cp->rx_skb[i] = skb;

cp->rx_ring[i].opts2 = 0;

2013-08-09 02:01:45

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 096/102] net_sched: info leak in atm_tc_dump_class()

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

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

From: Dan Carpenter <[email protected]>

[ Upstream commit 8cb3b9c3642c0263d48f31d525bcee7170eedc20 ]

The "pvc" struct has a hole after pvc.sap_family which is not cleared.

Signed-off-by: Dan Carpenter <[email protected]>
Reviewed-by: Jiri Pirko <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/sched/sch_atm.c | 1 +
1 file changed, 1 insertion(+)

--- a/net/sched/sch_atm.c
+++ b/net/sched/sch_atm.c
@@ -605,6 +605,7 @@ static int atm_tc_dump_class(struct Qdis
struct sockaddr_atmpvc pvc;
int state;

+ memset(&pvc, 0, sizeof(pvc));
pvc.sap_family = AF_ATMPVC;
pvc.sap_addr.itf = flow->vcc->dev ? flow->vcc->dev->number : -1;
pvc.sap_addr.vpi = flow->vcc->vpi;

2013-08-09 02:02:01

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 095/102] atl1c: use custom skb allocator

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

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

From: Eric Dumazet <[email protected]>

[ Upstream commit 7b70176421993866e616f1cbc4d0dd4054f1bf78 ]

We had reports ( https://bugzilla.kernel.org/show_bug.cgi?id=54021 )
that using high order pages for skb allocations is problematic for atl1c

We do not know exactly what the problem is, but we suspect that crossing
4K pages is not well supported by this hardware.

Use a custom allocator, using page allocator and 2K fragments for
optimal stack behavior. We might make this allocator generic
in future kernels.

Signed-off-by: Eric Dumazet <[email protected]>
Cc: Luis Henriques <[email protected]>
Cc: Neil Horman <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/ethernet/atheros/atl1c/atl1c.h | 3 +
drivers/net/ethernet/atheros/atl1c/atl1c_main.c | 40 +++++++++++++++++++++++-
2 files changed, 42 insertions(+), 1 deletion(-)

--- a/drivers/net/ethernet/atheros/atl1c/atl1c.h
+++ b/drivers/net/ethernet/atheros/atl1c/atl1c.h
@@ -520,6 +520,9 @@ struct atl1c_adapter {
struct net_device *netdev;
struct pci_dev *pdev;
struct napi_struct napi;
+ struct page *rx_page;
+ unsigned int rx_page_offset;
+ unsigned int rx_frag_size;
struct atl1c_hw hw;
struct atl1c_hw_stats hw_stats;
struct mii_if_info mii; /* MII interface info */
--- a/drivers/net/ethernet/atheros/atl1c/atl1c_main.c
+++ b/drivers/net/ethernet/atheros/atl1c/atl1c_main.c
@@ -481,10 +481,15 @@ static int atl1c_set_mac_addr(struct net
static void atl1c_set_rxbufsize(struct atl1c_adapter *adapter,
struct net_device *dev)
{
+ unsigned int head_size;
int mtu = dev->mtu;

adapter->rx_buffer_len = mtu > AT_RX_BUF_SIZE ?
roundup(mtu + ETH_HLEN + ETH_FCS_LEN + VLAN_HLEN, 8) : AT_RX_BUF_SIZE;
+
+ head_size = SKB_DATA_ALIGN(adapter->rx_buffer_len + NET_SKB_PAD) +
+ SKB_DATA_ALIGN(sizeof(struct skb_shared_info));
+ adapter->rx_frag_size = roundup_pow_of_two(head_size);
}

static netdev_features_t atl1c_fix_features(struct net_device *netdev,
@@ -952,6 +957,10 @@ static void atl1c_free_ring_resources(st
kfree(adapter->tpd_ring[0].buffer_info);
adapter->tpd_ring[0].buffer_info = NULL;
}
+ if (adapter->rx_page) {
+ put_page(adapter->rx_page);
+ adapter->rx_page = NULL;
+ }
}

/**
@@ -1639,6 +1648,35 @@ static inline void atl1c_rx_checksum(str
skb_checksum_none_assert(skb);
}

+static struct sk_buff *atl1c_alloc_skb(struct atl1c_adapter *adapter)
+{
+ struct sk_buff *skb;
+ struct page *page;
+
+ if (adapter->rx_frag_size > PAGE_SIZE)
+ return netdev_alloc_skb(adapter->netdev,
+ adapter->rx_buffer_len);
+
+ page = adapter->rx_page;
+ if (!page) {
+ adapter->rx_page = page = alloc_page(GFP_ATOMIC);
+ if (unlikely(!page))
+ return NULL;
+ adapter->rx_page_offset = 0;
+ }
+
+ skb = build_skb(page_address(page) + adapter->rx_page_offset,
+ adapter->rx_frag_size);
+ if (likely(skb)) {
+ adapter->rx_page_offset += adapter->rx_frag_size;
+ if (adapter->rx_page_offset >= PAGE_SIZE)
+ adapter->rx_page = NULL;
+ else
+ get_page(page);
+ }
+ return skb;
+}
+
static int atl1c_alloc_rx_buffer(struct atl1c_adapter *adapter)
{
struct atl1c_rfd_ring *rfd_ring = &adapter->rfd_ring;
@@ -1660,7 +1698,7 @@ static int atl1c_alloc_rx_buffer(struct
while (next_info->flags & ATL1C_BUFFER_FREE) {
rfd_desc = ATL1C_RFD_DESC(rfd_ring, rfd_next_to_use);

- skb = netdev_alloc_skb(adapter->netdev, adapter->rx_buffer_len);
+ skb = atl1c_alloc_skb(adapter);
if (unlikely(!skb)) {
if (netif_msg_rx_err(adapter))
dev_warn(&pdev->dev, "alloc rx buffer failed\n");

2013-08-09 02:02:24

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 094/102] af_key: more info leaks in pfkey messages

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

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

From: Dan Carpenter <[email protected]>

[ Upstream commit ff862a4668dd6dba962b1d2d8bd344afa6375683 ]

This is inspired by a5cc68f3d6 "af_key: fix info leaks in notify
messages". There are some struct members which don't get initialized
and could disclose small amounts of private information.

Acked-by: Mathias Krause <[email protected]>
Signed-off-by: Dan Carpenter <[email protected]>
Acked-by: Steffen Klassert <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/key/af_key.c | 4 ++++
1 file changed, 4 insertions(+)

--- a/net/key/af_key.c
+++ b/net/key/af_key.c
@@ -2081,6 +2081,7 @@ static int pfkey_xfrm_policy2msg(struct
pol->sadb_x_policy_type = IPSEC_POLICY_NONE;
}
pol->sadb_x_policy_dir = dir+1;
+ pol->sadb_x_policy_reserved = 0;
pol->sadb_x_policy_id = xp->index;
pol->sadb_x_policy_priority = xp->priority;

@@ -3137,7 +3138,9 @@ static int pfkey_send_acquire(struct xfr
pol->sadb_x_policy_exttype = SADB_X_EXT_POLICY;
pol->sadb_x_policy_type = IPSEC_POLICY_IPSEC;
pol->sadb_x_policy_dir = XFRM_POLICY_OUT + 1;
+ pol->sadb_x_policy_reserved = 0;
pol->sadb_x_policy_id = xp->index;
+ pol->sadb_x_policy_priority = xp->priority;

/* Set sadb_comb's. */
if (x->id.proto == IPPROTO_AH)
@@ -3525,6 +3528,7 @@ static int pfkey_send_migrate(const stru
pol->sadb_x_policy_exttype = SADB_X_EXT_POLICY;
pol->sadb_x_policy_type = IPSEC_POLICY_IPSEC;
pol->sadb_x_policy_dir = dir + 1;
+ pol->sadb_x_policy_reserved = 0;
pol->sadb_x_policy_id = 0;
pol->sadb_x_policy_priority = 0;


2013-08-09 01:59:39

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 085/102] x86/iommu/vt-d: Expand interrupt remapping quirk to cover x58 chipset

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

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

From: Neil Horman <[email protected]>

commit 803075dba31c17af110e1d9a915fe7262165b213 upstream.

Recently we added an early quirk to detect 5500/5520 chipsets
with early revisions that had problems with irq draining with
interrupt remapping enabled:

commit 03bbcb2e7e292838bb0244f5a7816d194c911d62
Author: Neil Horman <[email protected]>
Date: Tue Apr 16 16:38:32 2013 -0400

iommu/vt-d: add quirk for broken interrupt remapping on 55XX chipsets

It turns out this same problem is present in the intel X58
chipset as well. See errata 69 here:

http://www.intel.com/content/www/us/en/chipsets/x58-express-specification-update.html

This patch extends the pci early quirk so that the chip
devices/revisions specified in the above update are also covered
in the same way:

Signed-off-by: Neil Horman <[email protected]>
Reviewed-by: Jan Beulich <[email protected]>
Acked-by: Donald Dutile <[email protected]>
Cc: Joerg Roedel <[email protected]>
Cc: Andrew Cooper <[email protected]>
Cc: Malcolm Crossley <[email protected]>
Cc: Prarit Bhargava <[email protected]>
Cc: Don Zickus <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
[ Small edits. ]
Signed-off-by: Ingo Molnar <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/x86/kernel/early-quirks.c | 14 ++++++++++++--
1 file changed, 12 insertions(+), 2 deletions(-)

--- a/arch/x86/kernel/early-quirks.c
+++ b/arch/x86/kernel/early-quirks.c
@@ -196,15 +196,23 @@ static void __init ati_bugs_contd(int nu
static void __init intel_remapping_check(int num, int slot, int func)
{
u8 revision;
+ u16 device;

+ device = read_pci_config_16(num, slot, func, PCI_DEVICE_ID);
revision = read_pci_config_byte(num, slot, func, PCI_REVISION_ID);

/*
- * Revision 0x13 of this chipset supports irq remapping
- * but has an erratum that breaks its behavior, flag it as such
+ * Revision 13 of all triggering devices id in this quirk have
+ * a problem draining interrupts when irq remapping is enabled,
+ * and should be flagged as broken. Additionally revisions 0x12
+ * and 0x22 of device id 0x3405 has this problem.
*/
if (revision == 0x13)
set_irq_remapping_broken();
+ else if ((device == 0x3405) &&
+ ((revision == 0x12) ||
+ (revision == 0x22)))
+ set_irq_remapping_broken();

}

@@ -239,6 +247,8 @@ static struct chipset early_qrk[] __init
PCI_CLASS_SERIAL_SMBUS, PCI_ANY_ID, 0, ati_bugs_contd },
{ PCI_VENDOR_ID_INTEL, 0x3403, PCI_CLASS_BRIDGE_HOST,
PCI_BASE_CLASS_BRIDGE, 0, intel_remapping_check },
+ { PCI_VENDOR_ID_INTEL, 0x3405, PCI_CLASS_BRIDGE_HOST,
+ PCI_BASE_CLASS_BRIDGE, 0, intel_remapping_check },
{ PCI_VENDOR_ID_INTEL, 0x3406, PCI_CLASS_BRIDGE_HOST,
PCI_BASE_CLASS_BRIDGE, 0, intel_remapping_check },
{}

2013-08-09 02:02:43

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 083/102] workqueue: copy workqueue_attrs with all fields

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

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

From: Shaohua Li <[email protected]>

commit 2865a8fb44cc32420407362cbda80c10fa09c6b2 upstream.

$echo '0' > /sys/bus/workqueue/devices/xxx/numa
$cat /sys/bus/workqueue/devices/xxx/numa

I got 1. It should be 0, the reason is copy_workqueue_attrs() called
in apply_workqueue_attrs() doesn't copy no_numa field.

Fix it by making copy_workqueue_attrs() copy ->no_numa too. This
would also make get_unbound_pool() set a pool's ->no_numa attribute
according to the workqueue attributes used when the pool was created.
While harmelss, as ->no_numa isn't a pool attribute, this is a bit
confusing. Clear it explicitly.

tj: Updated description and comments a bit.

Signed-off-by: Shaohua Li <[email protected]>
Signed-off-by: Tejun Heo <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
kernel/workqueue.c | 12 ++++++++++++
1 file changed, 12 insertions(+)

--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -3398,6 +3398,12 @@ static void copy_workqueue_attrs(struct
{
to->nice = from->nice;
cpumask_copy(to->cpumask, from->cpumask);
+ /*
+ * Unlike hash and equality test, this function doesn't ignore
+ * ->no_numa as it is used for both pool and wq attrs. Instead,
+ * get_unbound_pool() explicitly clears ->no_numa after copying.
+ */
+ to->no_numa = from->no_numa;
}

/* hash value of the content of @attr */
@@ -3565,6 +3571,12 @@ static struct worker_pool *get_unbound_p
lockdep_set_subclass(&pool->lock, 1); /* see put_pwq() */
copy_workqueue_attrs(pool->attrs, attrs);

+ /*
+ * no_numa isn't a worker_pool attribute, always clear it. See
+ * 'struct workqueue_attrs' comments for detail.
+ */
+ pool->attrs->no_numa = false;
+
/* if cpumask is contained inside a NUMA node, we belong to that node */
if (wq_numa_enabled) {
for_each_node(node) {

2013-08-09 02:02:57

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 091/102] usbnet: do not pretend to support SG/TSO

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

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

From: Eric Dumazet <[email protected]>

[ Upstream commit 20f0170377264e8449b6987041f0bcc4d746d3ed ]

usbnet doesn't support yet SG, so drivers should not advertise SG or TSO
capabilities, as they allow TCP stack to build large TSO packets that
need to be linearized and might use order-5 pages.

This adds an extra copy overhead and possible allocation failures.

Current code ignore skb_linearize() return code so crashes are even
possible.

Best is to not pretend SG/TSO is supported, and add this again when/if
usbnet really supports SG for devices who could get a performance gain.

Based on a prior patch from Freddy Xin <[email protected]>

Signed-off-by: Eric Dumazet <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/usb/ax88179_178a.c | 9 ++++-----
drivers/net/usb/smsc75xx.c | 12 +++---------
2 files changed, 7 insertions(+), 14 deletions(-)

--- a/drivers/net/usb/ax88179_178a.c
+++ b/drivers/net/usb/ax88179_178a.c
@@ -1029,10 +1029,10 @@ static int ax88179_bind(struct usbnet *d
dev->mii.supports_gmii = 1;

dev->net->features |= NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM |
- NETIF_F_RXCSUM | NETIF_F_SG | NETIF_F_TSO;
+ NETIF_F_RXCSUM;

dev->net->hw_features |= NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM |
- NETIF_F_RXCSUM | NETIF_F_SG | NETIF_F_TSO;
+ NETIF_F_RXCSUM;

/* Enable checksum offload */
*tmp = AX_RXCOE_IP | AX_RXCOE_TCP | AX_RXCOE_UDP |
@@ -1173,7 +1173,6 @@ ax88179_tx_fixup(struct usbnet *dev, str
if (((skb->len + 8) % frame_size) == 0)
tx_hdr2 |= 0x80008000; /* Enable padding */

- skb_linearize(skb);
headroom = skb_headroom(skb);
tailroom = skb_tailroom(skb);

@@ -1317,10 +1316,10 @@ static int ax88179_reset(struct usbnet *
1, 1, tmp);

dev->net->features |= NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM |
- NETIF_F_RXCSUM | NETIF_F_SG | NETIF_F_TSO;
+ NETIF_F_RXCSUM;

dev->net->hw_features |= NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM |
- NETIF_F_RXCSUM | NETIF_F_SG | NETIF_F_TSO;
+ NETIF_F_RXCSUM;

/* Enable checksum offload */
*tmp = AX_RXCOE_IP | AX_RXCOE_TCP | AX_RXCOE_UDP |
--- a/drivers/net/usb/smsc75xx.c
+++ b/drivers/net/usb/smsc75xx.c
@@ -45,7 +45,6 @@
#define EEPROM_MAC_OFFSET (0x01)
#define DEFAULT_TX_CSUM_ENABLE (true)
#define DEFAULT_RX_CSUM_ENABLE (true)
-#define DEFAULT_TSO_ENABLE (true)
#define SMSC75XX_INTERNAL_PHY_ID (1)
#define SMSC75XX_TX_OVERHEAD (8)
#define MAX_RX_FIFO_SIZE (20 * 1024)
@@ -1410,17 +1409,14 @@ static int smsc75xx_bind(struct usbnet *

INIT_WORK(&pdata->set_multicast, smsc75xx_deferred_multicast_write);

- if (DEFAULT_TX_CSUM_ENABLE) {
+ if (DEFAULT_TX_CSUM_ENABLE)
dev->net->features |= NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM;
- if (DEFAULT_TSO_ENABLE)
- dev->net->features |= NETIF_F_SG |
- NETIF_F_TSO | NETIF_F_TSO6;
- }
+
if (DEFAULT_RX_CSUM_ENABLE)
dev->net->features |= NETIF_F_RXCSUM;

dev->net->hw_features = NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM |
- NETIF_F_SG | NETIF_F_TSO | NETIF_F_TSO6 | NETIF_F_RXCSUM;
+ NETIF_F_RXCSUM;

ret = smsc75xx_wait_ready(dev, 0);
if (ret < 0) {
@@ -2200,8 +2196,6 @@ static struct sk_buff *smsc75xx_tx_fixup
{
u32 tx_cmd_a, tx_cmd_b;

- skb_linearize(skb);
-
if (skb_headroom(skb) < SMSC75XX_TX_OVERHEAD) {
struct sk_buff *skb2 =
skb_copy_expand(skb, SMSC75XX_TX_OVERHEAD, 0, flags);

2013-08-09 02:03:19

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 090/102] ipv6: take rtnl_lock and mark mrt6 table as freed on namespace cleanup

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

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

From: Hannes Frederic Sowa <[email protected]>

[ Upstream commit 905a6f96a1b18e490a75f810d733ced93c39b0e5 ]

Otherwise we end up dereferencing the already freed net->ipv6.mrt pointer
which leads to a panic (from Srivatsa S. Bhat):

BUG: unable to handle kernel paging request at ffff882018552020
IP: [<ffffffffa0366b02>] ip6mr_sk_done+0x32/0xb0 [ipv6]
PGD 290a067 PUD 207ffe0067 PMD 207ff1d067 PTE 8000002018552060
Oops: 0000 [#1] SMP DEBUG_PAGEALLOC
Modules linked in: ebtable_nat ebtables nfs fscache nf_conntrack_ipv4 nf_defrag_ipv4 ipt_REJECT xt_CHECKSUM iptable_mangle iptable_filter ip_tables nfsd lockd nfs_acl exportfs auth_rpcgss autofs4 sunrpc 8021q garp bridge stp llc ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter
+ip6_tables ipv6 vfat fat vhost_net macvtap macvlan vhost tun kvm_intel kvm uinput iTCO_wdt iTCO_vendor_support cdc_ether usbnet mii microcode i2c_i801 i2c_core lpc_ich mfd_core shpchp ioatdma dca mlx4_core be2net wmi acpi_cpufreq mperf ext4 jbd2 mbcache dm_mirror dm_region_hash dm_log dm_mod
CPU: 0 PID: 7 Comm: kworker/u33:0 Not tainted 3.11.0-rc1-ea45e-a #4
Hardware name: IBM -[8737R2A]-/00Y2738, BIOS -[B2E120RUS-1.20]- 11/30/2012
Workqueue: netns cleanup_net
task: ffff8810393641c0 ti: ffff881039366000 task.ti: ffff881039366000
RIP: 0010:[<ffffffffa0366b02>] [<ffffffffa0366b02>] ip6mr_sk_done+0x32/0xb0 [ipv6]
RSP: 0018:ffff881039367bd8 EFLAGS: 00010286
RAX: ffff881039367fd8 RBX: ffff882018552000 RCX: dead000000200200
RDX: 0000000000000000 RSI: ffff881039367b68 RDI: ffff881039367b68
RBP: ffff881039367bf8 R08: ffff881039367b68 R09: 2222222222222222
R10: 2222222222222222 R11: 2222222222222222 R12: ffff882015a7a040
R13: ffff882014eb89c0 R14: ffff8820289e2800 R15: 0000000000000000
FS: 0000000000000000(0000) GS:ffff88103fc00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffff882018552020 CR3: 0000000001c0b000 CR4: 00000000000407f0
Stack:
ffff881039367c18 ffff882014eb89c0 ffff882015e28c00 0000000000000000
ffff881039367c18 ffffffffa034d9d1 ffff8820289e2800 ffff882014eb89c0
ffff881039367c58 ffffffff815bdecb ffffffff815bddf2 ffff882014eb89c0
Call Trace:
[<ffffffffa034d9d1>] rawv6_close+0x21/0x40 [ipv6]
[<ffffffff815bdecb>] inet_release+0xfb/0x220
[<ffffffff815bddf2>] ? inet_release+0x22/0x220
[<ffffffffa032686f>] inet6_release+0x3f/0x50 [ipv6]
[<ffffffff8151c1d9>] sock_release+0x29/0xa0
[<ffffffff81525520>] sk_release_kernel+0x30/0x70
[<ffffffffa034f14b>] icmpv6_sk_exit+0x3b/0x80 [ipv6]
[<ffffffff8152fff9>] ops_exit_list+0x39/0x60
[<ffffffff815306fb>] cleanup_net+0xfb/0x1a0
[<ffffffff81075e3a>] process_one_work+0x1da/0x610
[<ffffffff81075dc9>] ? process_one_work+0x169/0x610
[<ffffffff81076390>] worker_thread+0x120/0x3a0
[<ffffffff81076270>] ? process_one_work+0x610/0x610
[<ffffffff8107da2e>] kthread+0xee/0x100
[<ffffffff8107d940>] ? __init_kthread_worker+0x70/0x70
[<ffffffff8162a99c>] ret_from_fork+0x7c/0xb0
[<ffffffff8107d940>] ? __init_kthread_worker+0x70/0x70
Code: 20 48 89 5d e8 4c 89 65 f0 4c 89 6d f8 66 66 66 66 90 4c 8b 67 30 49 89 fd e8 db 3c 1e e1 49 8b 9c 24 90 08 00 00 48 85 db 74 06 <4c> 39 6b 20 74 20 bb f3 ff ff ff e8 8e 3c 1e e1 89 d8 4c 8b 65
RIP [<ffffffffa0366b02>] ip6mr_sk_done+0x32/0xb0 [ipv6]
RSP <ffff881039367bd8>
CR2: ffff882018552020

Reported-by: Srivatsa S. Bhat <[email protected]>
Tested-by: Srivatsa S. Bhat <[email protected]>
Signed-off-by: Hannes Frederic Sowa <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/ipv6/ip6mr.c | 5 +++++
1 file changed, 5 insertions(+)

--- a/net/ipv6/ip6mr.c
+++ b/net/ipv6/ip6mr.c
@@ -259,10 +259,12 @@ static void __net_exit ip6mr_rules_exit(
{
struct mr6_table *mrt, *next;

+ rtnl_lock();
list_for_each_entry_safe(mrt, next, &net->ipv6.mr6_tables, list) {
list_del(&mrt->list);
ip6mr_free_table(mrt);
}
+ rtnl_unlock();
fib_rules_unregister(net->ipv6.mr6_rules_ops);
}
#else
@@ -289,7 +291,10 @@ static int __net_init ip6mr_rules_init(s

static void __net_exit ip6mr_rules_exit(struct net *net)
{
+ rtnl_lock();
ip6mr_free_table(net->ipv6.mrt6);
+ net->ipv6.mrt6 = NULL;
+ rtnl_unlock();
}
#endif


2013-08-09 01:59:36

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 081/102] s390: add support for IBM zBC12 machine

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

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

From: Heiko Carstens <[email protected]>

commit 594712276e737961d30e11eae80d403b2b3815df upstream.

Just add the new model number where appropiate.

Signed-off-by: Heiko Carstens <[email protected]>
Signed-off-by: Martin Schwidefsky <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/s390/Kconfig | 7 ++++---
arch/s390/kernel/setup.c | 1 +
arch/s390/mm/init.c | 1 +
arch/s390/oprofile/init.c | 2 +-
4 files changed, 7 insertions(+), 4 deletions(-)

--- a/arch/s390/Kconfig
+++ b/arch/s390/Kconfig
@@ -227,11 +227,12 @@ config MARCH_Z196
not work on older machines.

config MARCH_ZEC12
- bool "IBM zEC12"
+ bool "IBM zBC12 and zEC12"
select HAVE_MARCH_ZEC12_FEATURES if 64BIT
help
- Select this to enable optimizations for IBM zEC12 (2827 series). The
- kernel will be slightly faster but will not work on older machines.
+ Select this to enable optimizations for IBM zBC12 and zEC12 (2828 and
+ 2827 series). The kernel will be slightly faster but will not work on
+ older machines.

endchoice

--- a/arch/s390/kernel/setup.c
+++ b/arch/s390/kernel/setup.c
@@ -998,6 +998,7 @@ static void __init setup_hwcaps(void)
strcpy(elf_platform, "z196");
break;
case 0x2827:
+ case 0x2828:
strcpy(elf_platform, "zEC12");
break;
}
--- a/arch/s390/mm/init.c
+++ b/arch/s390/mm/init.c
@@ -69,6 +69,7 @@ static void __init setup_zero_pages(void
order = 2;
break;
case 0x2827: /* zEC12 */
+ case 0x2828: /* zEC12 */
default:
order = 5;
break;
--- a/arch/s390/oprofile/init.c
+++ b/arch/s390/oprofile/init.c
@@ -440,7 +440,7 @@ static int oprofile_hwsampler_init(struc
switch (id.machine) {
case 0x2097: case 0x2098: ops->cpu_type = "s390/z10"; break;
case 0x2817: case 0x2818: ops->cpu_type = "s390/z196"; break;
- case 0x2827: ops->cpu_type = "s390/zEC12"; break;
+ case 0x2827: case 0x2828: ops->cpu_type = "s390/zEC12"; break;
default: return -ENODEV;
}
}

2013-08-09 02:03:38

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 089/102] sfc: Enable RX scatter for flows steered by RFS

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

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

From: Ben Hutchings <[email protected]>

[ Upstream commit 7aa0076c497d6f0d5d957b431d0d80e1e9780274 ]

Received packets are only scattered if this is enabled in both the
matching filter and the receiving queue. This was not being done for
filters inserted for RFS, so any packet requiring more than a single
descriptor was dropped.

Signed-off-by: Ben Hutchings <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/ethernet/sfc/filter.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)

--- a/drivers/net/ethernet/sfc/filter.c
+++ b/drivers/net/ethernet/sfc/filter.c
@@ -1196,7 +1196,9 @@ int efx_filter_rfs(struct net_device *ne
EFX_BUG_ON_PARANOID(skb_headlen(skb) < nhoff + 4 * ip->ihl + 4);
ports = (const __be16 *)(skb->data + nhoff + 4 * ip->ihl);

- efx_filter_init_rx(&spec, EFX_FILTER_PRI_HINT, 0, rxq_index);
+ efx_filter_init_rx(&spec, EFX_FILTER_PRI_HINT,
+ efx->rx_scatter ? EFX_FILTER_FLAG_RX_SCATTER : 0,
+ rxq_index);
rc = efx_filter_set_ipv4_full(&spec, ip->protocol,
ip->daddr, ports[1], ip->saddr, ports[0]);
if (rc)

2013-08-09 02:03:52

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 088/102] sysctl net: Keep tcp_syn_retries inside the boundary

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

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

From: Michal Tesar <[email protected]>

[ Upstream commit 651e92716aaae60fc41b9652f54cb6803896e0da ]

Limit the min/max value passed to the
/proc/sys/net/ipv4/tcp_syn_retries.

Signed-off-by: Michal Tesar <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/ipv4/sysctl_net_ipv4.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)

--- a/net/ipv4/sysctl_net_ipv4.c
+++ b/net/ipv4/sysctl_net_ipv4.c
@@ -36,6 +36,8 @@ static int tcp_adv_win_scale_min = -31;
static int tcp_adv_win_scale_max = 31;
static int ip_ttl_min = 1;
static int ip_ttl_max = 255;
+static int tcp_syn_retries_min = 1;
+static int tcp_syn_retries_max = MAX_TCP_SYNCNT;
static int ip_ping_group_range_min[] = { 0, 0 };
static int ip_ping_group_range_max[] = { GID_T_MAX, GID_T_MAX };

@@ -331,7 +333,9 @@ static struct ctl_table ipv4_table[] = {
.data = &sysctl_tcp_syn_retries,
.maxlen = sizeof(int),
.mode = 0644,
- .proc_handler = proc_dointvec
+ .proc_handler = proc_dointvec_minmax,
+ .extra1 = &tcp_syn_retries_min,
+ .extra2 = &tcp_syn_retries_max
},
{
.procname = "tcp_synack_retries",

2013-08-09 02:04:13

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 087/102] arcnet: cleanup sizeof parameter

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

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

From: Dan Carpenter <[email protected]>

[ Upstream commit 087d273caf4f7d3f2159256f255f1f432bc84a5b ]

This patch doesn't change the compiled code because ARC_HDR_SIZE is 4
and sizeof(int) is 4, but the intent was to use the header size and not
the sizeof the header size.

Signed-off-by: Dan Carpenter <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/arcnet/arcnet.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/net/arcnet/arcnet.c
+++ b/drivers/net/arcnet/arcnet.c
@@ -1007,7 +1007,7 @@ static void arcnet_rx(struct net_device

soft = &pkt.soft.rfc1201;

- lp->hw.copy_from_card(dev, bufnum, 0, &pkt, sizeof(ARC_HDR_SIZE));
+ lp->hw.copy_from_card(dev, bufnum, 0, &pkt, ARC_HDR_SIZE);
if (pkt.hard.offset[0]) {
ofs = pkt.hard.offset[0];
length = 256 - ofs;

2013-08-09 02:04:33

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 086/102] spi: spi-davinci: Fix direction in dma_map_single()

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

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

From: Christian Eggers <[email protected]>

commit 89c66ee890af18500fa4598db300cc07c267f900 upstream.

Commit 048177ce3b3962852fd34a7e04938959271c7e70 (spi: spi-davinci:
convert to DMA engine API) introduced a regression: dma_map_single()
is called with direction DMA_FROM_DEVICE for rx and for tx.

Signed-off-by: Christian Eggers <[email protected]>
Acked-by: Matt Porter <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/spi/spi-davinci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/spi/spi-davinci.c
+++ b/drivers/spi/spi-davinci.c
@@ -610,7 +610,7 @@ static int davinci_spi_bufs(struct spi_d
else
buf = (void *)t->tx_buf;
t->tx_dma = dma_map_single(&spi->dev, buf,
- t->len, DMA_FROM_DEVICE);
+ t->len, DMA_TO_DEVICE);
if (!t->tx_dma) {
ret = -EFAULT;
goto err_tx_map;

2013-08-09 02:04:54

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 084/102] userns: unshare_userns(&cred) should not populate cred on failure

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

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

From: Oleg Nesterov <[email protected]>

commit 6160968cee8b90a5dd95318d716e31d7775c4ef3 upstream.

unshare_userns(new_cred) does *new_cred = prepare_creds() before
create_user_ns() which can fail. However, the caller expects that
it doesn't need to take care of new_cred if unshare_userns() fails.

We could change the single caller, sys_unshare(), but I think it
would be more clean to avoid the side effects on failure, so with
this patch unshare_userns() does put_cred() itself and initializes
*new_cred only if create_user_ns() succeeeds.

Signed-off-by: Oleg Nesterov <[email protected]>
Reviewed-by: Andy Lutomirski <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
kernel/user_namespace.c | 13 +++++++++----
1 file changed, 9 insertions(+), 4 deletions(-)

--- a/kernel/user_namespace.c
+++ b/kernel/user_namespace.c
@@ -105,16 +105,21 @@ int create_user_ns(struct cred *new)
int unshare_userns(unsigned long unshare_flags, struct cred **new_cred)
{
struct cred *cred;
+ int err = -ENOMEM;

if (!(unshare_flags & CLONE_NEWUSER))
return 0;

cred = prepare_creds();
- if (!cred)
- return -ENOMEM;
+ if (cred) {
+ err = create_user_ns(cred);
+ if (err)
+ put_cred(cred);
+ else
+ *new_cred = cred;
+ }

- *new_cred = cred;
- return create_user_ns(cred);
+ return err;
}

void free_user_ns(struct user_namespace *ns)

2013-08-09 02:05:18

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 075/102] fanotify: info leak in copy_event_to_user()

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

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

From: Dan Carpenter <[email protected]>

commit de1e0c40aceb9d5bff09c3a3b97b2f1b178af53f upstream.

The ->reserved field isn't cleared so we leak one byte of stack
information to userspace.

Signed-off-by: Dan Carpenter <[email protected]>
Cc: Eric Paris <[email protected]>
Cc: Al Viro <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Cc: Luis Henriques <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
fs/notify/fanotify/fanotify_user.c | 1 +
1 file changed, 1 insertion(+)

--- a/fs/notify/fanotify/fanotify_user.c
+++ b/fs/notify/fanotify/fanotify_user.c
@@ -122,6 +122,7 @@ static int fill_event_metadata(struct fs
metadata->event_len = FAN_EVENT_METADATA_LEN;
metadata->metadata_len = FAN_EVENT_METADATA_LEN;
metadata->vers = FANOTIFY_METADATA_VERSION;
+ metadata->reserved = 0;
metadata->mask = event->mask & FAN_ALL_OUTGOING_EVENTS;
metadata->pid = pid_vnr(event->tgid);
if (unlikely(event->mask & FAN_Q_OVERFLOW))

2013-08-09 02:05:43

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 080/102] drm/i915: make SDVO TV-out work for multifunction devices

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

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

From: Daniel Vetter <[email protected]>

commit 09ede5414f0215461c933032630bf9c3a61a8ba3 upstream.

We need to track this correctly. While at it shovel the boolean
to track whether the sdvo is in tv mode or not into pipe_config.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=36997
Tested-by: Pierre Assal <[email protected]>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=63609
Tested-by: cancan,feng <[email protected]>
Reviewed-by: Jani Nikula <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>


---
drivers/gpu/drm/i915/intel_display.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)

--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4333,7 +4333,8 @@ static void vlv_update_pll(struct intel_

static void i9xx_update_pll(struct intel_crtc *crtc,
intel_clock_t *reduced_clock,
- int num_connectors)
+ int num_connectors,
+ bool needs_tv_clock)
{
struct drm_device *dev = crtc->base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
@@ -4391,7 +4392,7 @@ static void i9xx_update_pll(struct intel
if (INTEL_INFO(dev)->gen >= 4)
dpll |= (6 << PLL_LOAD_PULSE_PHASE_SHIFT);

- if (is_sdvo && intel_pipe_has_type(&crtc->base, INTEL_OUTPUT_TVOUT))
+ if (is_sdvo && needs_tv_clock)
dpll |= PLL_REF_INPUT_TVCLKINBC;
else if (intel_pipe_has_type(&crtc->base, INTEL_OUTPUT_TVOUT))
/* XXX: just matching BIOS for now */
@@ -4716,7 +4717,8 @@ static int i9xx_crtc_mode_set(struct drm
else
i9xx_update_pll(intel_crtc,
has_reduced_clock ? &reduced_clock : NULL,
- num_connectors);
+ num_connectors,
+ is_sdvo && is_tv);

/* Set up the display plane register */
dspcntr = DISPPLANE_GAMMA_ENABLE;

2013-08-09 02:05:58

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 079/102] Btrfs: fix crash regarding to ulist_add_merge

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

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

From: Liu Bo <[email protected]>

commit 35f0399db6658f465b00893bdd13b992a0acfef0 upstream.

Several users reported this crash of NULL pointer or general protection,
the story is that we add a rbtree for speedup ulist iteration, and we
use krealloc() to address ulist growth, and krealloc() use memcpy to copy
old data to new memory area, so it's OK for an array as it doesn't use
pointers while it's not OK for a rbtree as it uses pointers.

So krealloc() will mess up our rbtree and it ends up with crash.

Reviewed-by: Wang Shilong <[email protected]>
Signed-off-by: Liu Bo <[email protected]>
Signed-off-by: Josef Bacik <[email protected]>
Cc: BJ Quinn <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
fs/btrfs/ulist.c | 15 +++++++++++++++
1 file changed, 15 insertions(+)

--- a/fs/btrfs/ulist.c
+++ b/fs/btrfs/ulist.c
@@ -205,6 +205,10 @@ int ulist_add_merge(struct ulist *ulist,
u64 new_alloced = ulist->nodes_alloced + 128;
struct ulist_node *new_nodes;
void *old = NULL;
+ int i;
+
+ for (i = 0; i < ulist->nnodes; i++)
+ rb_erase(&ulist->nodes[i].rb_node, &ulist->root);

/*
* if nodes_alloced == ULIST_SIZE no memory has been allocated
@@ -224,6 +228,17 @@ int ulist_add_merge(struct ulist *ulist,

ulist->nodes = new_nodes;
ulist->nodes_alloced = new_alloced;
+
+ /*
+ * krealloc actually uses memcpy, which does not copy rb_node
+ * pointers, so we have to do it ourselves. Otherwise we may
+ * be bitten by crashes.
+ */
+ for (i = 0; i < ulist->nnodes; i++) {
+ ret = ulist_rbtree_insert(ulist, &ulist->nodes[i]);
+ if (ret < 0)
+ return ret;
+ }
}
ulist->nodes[ulist->nnodes].val = val;
ulist->nodes[ulist->nnodes].aux = aux;

2013-08-09 01:59:26

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 072/102] drm/radeon: Disable dma rings for bo moves on r6xx

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

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

From: Alex Deucher <[email protected]>

commit aeea40cbf9388fc829e66fa049f64d97fd72e118 upstream.

They still seem to cause instability on some r6xx parts.
As a follow up, we can switch to using CP DMA for bo
moves on r6xx as a lighter weight alternative to using
the 3D engine.

A version of this patch should also go to stable kernels.

Tested-by: J.N. <[email protected]>
Reviewed-by: Christian König <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/gpu/drm/radeon/radeon_asic.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)

--- a/drivers/gpu/drm/radeon/radeon_asic.c
+++ b/drivers/gpu/drm/radeon/radeon_asic.c
@@ -986,8 +986,8 @@ static struct radeon_asic r600_asic = {
.blit_ring_index = RADEON_RING_TYPE_GFX_INDEX,
.dma = &r600_copy_dma,
.dma_ring_index = R600_RING_TYPE_DMA_INDEX,
- .copy = &r600_copy_dma,
- .copy_ring_index = R600_RING_TYPE_DMA_INDEX,
+ .copy = &r600_copy_blit,
+ .copy_ring_index = RADEON_RING_TYPE_GFX_INDEX,
},
.surface = {
.set_reg = r600_set_surface_reg,
@@ -1074,8 +1074,8 @@ static struct radeon_asic rs780_asic = {
.blit_ring_index = RADEON_RING_TYPE_GFX_INDEX,
.dma = &r600_copy_dma,
.dma_ring_index = R600_RING_TYPE_DMA_INDEX,
- .copy = &r600_copy_dma,
- .copy_ring_index = R600_RING_TYPE_DMA_INDEX,
+ .copy = &r600_copy_blit,
+ .copy_ring_index = RADEON_RING_TYPE_GFX_INDEX,
},
.surface = {
.set_reg = r600_set_surface_reg,

2013-08-09 02:06:23

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 078/102] x86, fpu: correct the asm constraints for fxsave, unbreak mxcsr.daz

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

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

From: "H.J. Lu" <[email protected]>

commit eaa5a990191d204ba0f9d35dbe5505ec2cdd1460 upstream.

GCC will optimize mxcsr_feature_mask_init in arch/x86/kernel/i387.c:

memset(&fx_scratch, 0, sizeof(struct i387_fxsave_struct));
asm volatile("fxsave %0" : : "m" (fx_scratch));
mask = fx_scratch.mxcsr_mask;
if (mask == 0)
mask = 0x0000ffbf;

to

memset(&fx_scratch, 0, sizeof(struct i387_fxsave_struct));
asm volatile("fxsave %0" : : "m" (fx_scratch));
mask = 0x0000ffbf;

since asm statement doesn’t say it will update fx_scratch. As the
result, the DAZ bit will be cleared. This patch fixes it. This bug
dates back to at least kernel 2.6.12.

Signed-off-by: H. Peter Anvin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/x86/kernel/i387.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/arch/x86/kernel/i387.c
+++ b/arch/x86/kernel/i387.c
@@ -116,7 +116,7 @@ static void __cpuinit mxcsr_feature_mask

if (cpu_has_fxsr) {
memset(&fx_scratch, 0, sizeof(struct i387_fxsave_struct));
- asm volatile("fxsave %0" : : "m" (fx_scratch));
+ asm volatile("fxsave %0" : "+m" (fx_scratch));
mask = fx_scratch.mxcsr_mask;
if (mask == 0)
mask = 0x0000ffbf;

2013-08-09 02:06:40

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 077/102] drm/radeon: never unpin UVD bo v3

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

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

From: Christian König <[email protected]>

commit 9cc2e0e9f13315559c85c9f99f141e420967c955 upstream.

Changing the UVD BOs offset on suspend/resume doesn't work because the VCPU
internally keeps pointers to it. Just keep it always pinned and save the
content manually.

Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=66425

v2: fix compiler warning
v3: fix CIK support
v4: rebased for 3.10-stable tree

Note: a version of this patch needs to go to stable.

Signed-off-by: Christian König <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>


---
drivers/gpu/drm/radeon/radeon.h | 3 -
drivers/gpu/drm/radeon/radeon_fence.c | 2
drivers/gpu/drm/radeon/radeon_uvd.c | 100 ++++++++++++++++------------------
drivers/gpu/drm/radeon/rv770.c | 2
4 files changed, 52 insertions(+), 55 deletions(-)

--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -1145,6 +1145,8 @@ struct radeon_uvd {
struct radeon_bo *vcpu_bo;
void *cpu_addr;
uint64_t gpu_addr;
+ void *saved_bo;
+ unsigned fw_size;
atomic_t handles[RADEON_MAX_UVD_HANDLES];
struct drm_file *filp[RADEON_MAX_UVD_HANDLES];
struct delayed_work idle_work;
@@ -1684,7 +1686,6 @@ struct radeon_device {
const struct firmware *rlc_fw; /* r6/700 RLC firmware */
const struct firmware *mc_fw; /* NI MC firmware */
const struct firmware *ce_fw; /* SI CE firmware */
- const struct firmware *uvd_fw; /* UVD firmware */
struct r600_blit r600_blit;
struct r600_vram_scratch vram_scratch;
int msi_enabled; /* msi enabled */
--- a/drivers/gpu/drm/radeon/radeon_fence.c
+++ b/drivers/gpu/drm/radeon/radeon_fence.c
@@ -782,7 +782,7 @@ int radeon_fence_driver_start_ring(struc

} else {
/* put fence directly behind firmware */
- index = ALIGN(rdev->uvd_fw->size, 8);
+ index = ALIGN(rdev->uvd.fw_size, 8);
rdev->fence_drv[ring].cpu_addr = rdev->uvd.cpu_addr + index;
rdev->fence_drv[ring].gpu_addr = rdev->uvd.gpu_addr + index;
}
--- a/drivers/gpu/drm/radeon/radeon_uvd.c
+++ b/drivers/gpu/drm/radeon/radeon_uvd.c
@@ -55,6 +55,7 @@ static void radeon_uvd_idle_work_handler
int radeon_uvd_init(struct radeon_device *rdev)
{
struct platform_device *pdev;
+ const struct firmware *fw;
unsigned long bo_size;
const char *fw_name;
int i, r;
@@ -104,7 +105,7 @@ int radeon_uvd_init(struct radeon_device
return -EINVAL;
}

- r = request_firmware(&rdev->uvd_fw, fw_name, &pdev->dev);
+ r = request_firmware(&fw, fw_name, &pdev->dev);
if (r) {
dev_err(rdev->dev, "radeon_uvd: Can't load firmware \"%s\"\n",
fw_name);
@@ -114,7 +115,7 @@ int radeon_uvd_init(struct radeon_device

platform_device_unregister(pdev);

- bo_size = RADEON_GPU_PAGE_ALIGN(rdev->uvd_fw->size + 8) +
+ bo_size = RADEON_GPU_PAGE_ALIGN(fw->size + 8) +
RADEON_UVD_STACK_SIZE + RADEON_UVD_HEAP_SIZE;
r = radeon_bo_create(rdev, bo_size, PAGE_SIZE, true,
RADEON_GEM_DOMAIN_VRAM, NULL, &rdev->uvd.vcpu_bo);
@@ -123,16 +124,35 @@ int radeon_uvd_init(struct radeon_device
return r;
}

- r = radeon_uvd_resume(rdev);
- if (r)
+ r = radeon_bo_reserve(rdev->uvd.vcpu_bo, false);
+ if (r) {
+ radeon_bo_unref(&rdev->uvd.vcpu_bo);
+ dev_err(rdev->dev, "(%d) failed to reserve UVD bo\n", r);
return r;
+ }

- memset(rdev->uvd.cpu_addr, 0, bo_size);
- memcpy(rdev->uvd.cpu_addr, rdev->uvd_fw->data, rdev->uvd_fw->size);
+ r = radeon_bo_pin(rdev->uvd.vcpu_bo, RADEON_GEM_DOMAIN_VRAM,
+ &rdev->uvd.gpu_addr);
+ if (r) {
+ radeon_bo_unreserve(rdev->uvd.vcpu_bo);
+ radeon_bo_unref(&rdev->uvd.vcpu_bo);
+ dev_err(rdev->dev, "(%d) UVD bo pin failed\n", r);
+ return r;
+ }

- r = radeon_uvd_suspend(rdev);
- if (r)
+ r = radeon_bo_kmap(rdev->uvd.vcpu_bo, &rdev->uvd.cpu_addr);
+ if (r) {
+ dev_err(rdev->dev, "(%d) UVD map failed\n", r);
return r;
+ }
+
+ radeon_bo_unreserve(rdev->uvd.vcpu_bo);
+
+ rdev->uvd.fw_size = fw->size;
+ memset(rdev->uvd.cpu_addr, 0, bo_size);
+ memcpy(rdev->uvd.cpu_addr, fw->data, fw->size);
+
+ release_firmware(fw);

for (i = 0; i < RADEON_MAX_UVD_HANDLES; ++i) {
atomic_set(&rdev->uvd.handles[i], 0);
@@ -144,71 +164,47 @@ int radeon_uvd_init(struct radeon_device

void radeon_uvd_fini(struct radeon_device *rdev)
{
- radeon_uvd_suspend(rdev);
- radeon_bo_unref(&rdev->uvd.vcpu_bo);
-}
-
-int radeon_uvd_suspend(struct radeon_device *rdev)
-{
int r;

if (rdev->uvd.vcpu_bo == NULL)
- return 0;
+ return;

r = radeon_bo_reserve(rdev->uvd.vcpu_bo, false);
if (!r) {
radeon_bo_kunmap(rdev->uvd.vcpu_bo);
radeon_bo_unpin(rdev->uvd.vcpu_bo);
- rdev->uvd.cpu_addr = NULL;
- if (!radeon_bo_pin(rdev->uvd.vcpu_bo, RADEON_GEM_DOMAIN_CPU, NULL)) {
- radeon_bo_kmap(rdev->uvd.vcpu_bo, &rdev->uvd.cpu_addr);
- }
radeon_bo_unreserve(rdev->uvd.vcpu_bo);
-
- if (rdev->uvd.cpu_addr) {
- radeon_fence_driver_start_ring(rdev, R600_RING_TYPE_UVD_INDEX);
- } else {
- rdev->fence_drv[R600_RING_TYPE_UVD_INDEX].cpu_addr = NULL;
- }
}
- return r;
+
+ radeon_bo_unref(&rdev->uvd.vcpu_bo);
}

-int radeon_uvd_resume(struct radeon_device *rdev)
+int radeon_uvd_suspend(struct radeon_device *rdev)
{
- int r;
+ unsigned size;

if (rdev->uvd.vcpu_bo == NULL)
- return -EINVAL;
+ return 0;

- r = radeon_bo_reserve(rdev->uvd.vcpu_bo, false);
- if (r) {
- radeon_bo_unref(&rdev->uvd.vcpu_bo);
- dev_err(rdev->dev, "(%d) failed to reserve UVD bo\n", r);
- return r;
- }
+ size = radeon_bo_size(rdev->uvd.vcpu_bo);
+ rdev->uvd.saved_bo = kmalloc(size, GFP_KERNEL);
+ memcpy(rdev->uvd.saved_bo, rdev->uvd.cpu_addr, size);

- /* Have been pin in cpu unmap unpin */
- radeon_bo_kunmap(rdev->uvd.vcpu_bo);
- radeon_bo_unpin(rdev->uvd.vcpu_bo);
+ return 0;
+}

- r = radeon_bo_pin(rdev->uvd.vcpu_bo, RADEON_GEM_DOMAIN_VRAM,
- &rdev->uvd.gpu_addr);
- if (r) {
- radeon_bo_unreserve(rdev->uvd.vcpu_bo);
- radeon_bo_unref(&rdev->uvd.vcpu_bo);
- dev_err(rdev->dev, "(%d) UVD bo pin failed\n", r);
- return r;
- }
+int radeon_uvd_resume(struct radeon_device *rdev)
+{
+ if (rdev->uvd.vcpu_bo == NULL)
+ return -EINVAL;

- r = radeon_bo_kmap(rdev->uvd.vcpu_bo, &rdev->uvd.cpu_addr);
- if (r) {
- dev_err(rdev->dev, "(%d) UVD map failed\n", r);
- return r;
+ if (rdev->uvd.saved_bo != NULL) {
+ unsigned size = radeon_bo_size(rdev->uvd.vcpu_bo);
+ memcpy(rdev->uvd.cpu_addr, rdev->uvd.saved_bo, size);
+ kfree(rdev->uvd.saved_bo);
+ rdev->uvd.saved_bo = NULL;
}

- radeon_bo_unreserve(rdev->uvd.vcpu_bo);
-
return 0;
}

--- a/drivers/gpu/drm/radeon/rv770.c
+++ b/drivers/gpu/drm/radeon/rv770.c
@@ -813,7 +813,7 @@ int rv770_uvd_resume(struct radeon_devic

/* programm the VCPU memory controller bits 0-27 */
addr = rdev->uvd.gpu_addr >> 3;
- size = RADEON_GPU_PAGE_ALIGN(rdev->uvd_fw->size + 4) >> 3;
+ size = RADEON_GPU_PAGE_ALIGN(rdev->uvd.fw_size + 4) >> 3;
WREG32(UVD_VCPU_CACHE_OFFSET0, addr);
WREG32(UVD_VCPU_CACHE_SIZE0, size);


2013-08-09 02:06:58

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 076/102] cgroup: fix umount vs cgroup_cfts_commit() race

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

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

From: Li Zefan <[email protected]>

commit 084457f284abf6789d90509ee11dae383842b23b upstream.

cgroup_cfts_commit() uses dget() to keep cgroup alive after cgroup_mutex
is dropped, but dget() won't prevent cgroupfs from being umounted. When
the race happens, vfs will see some dentries with non-zero refcnt while
umount is in process.

Keep running this:
mount -t cgroup -o blkio xxx /cgroup
umount /cgroup

And this:
modprobe cfq-iosched
rmmod cfs-iosched

After a while, the BUG() in shrink_dcache_for_umount_subtree() may
be triggered:

BUG: Dentry xxx{i=0,n=blkio.yyy} still in use (1) [umount of cgroup cgroup]

Signed-off-by: Li Zefan <[email protected]>
Signed-off-by: Tejun Heo <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
kernel/cgroup.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)

--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -2769,13 +2769,17 @@ static void cgroup_cfts_commit(struct cg
{
LIST_HEAD(pending);
struct cgroup *cgrp, *n;
+ struct super_block *sb = ss->root->sb;

/* %NULL @cfts indicates abort and don't bother if @ss isn't attached */
- if (cfts && ss->root != &rootnode) {
+ if (cfts && ss->root != &rootnode &&
+ atomic_inc_not_zero(&sb->s_active)) {
list_for_each_entry(cgrp, &ss->root->allcg_list, allcg_node) {
dget(cgrp->dentry);
list_add_tail(&cgrp->cft_q_node, &pending);
}
+ } else {
+ sb = NULL;
}

mutex_unlock(&cgroup_mutex);
@@ -2798,6 +2802,9 @@ static void cgroup_cfts_commit(struct cg
dput(cgrp->dentry);
}

+ if (sb)
+ deactivate_super(sb);
+
mutex_unlock(&cgroup_cft_mutex);
}


2013-08-09 02:07:22

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 067/102] Revert "cpuidle: Quickly notice prediction failure in general case"

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

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

From: "Rafael J. Wysocki" <[email protected]>

commit 228b30234f258a193317874854eee1ca7807186e upstream.

Revert commit e11538d1 (cpuidle: Quickly notice prediction failure in
general case), since it depends on commit 69a37be (cpuidle: Quickly
notice prediction failure for repeat mode) that has been identified
as the source of a significant performance regression in v3.8 and
later.

Requested-by: Jeremy Eder <[email protected]>
Tested-by: Len Brown <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/cpuidle/governors/menu.c | 35 +----------------------------------
1 file changed, 1 insertion(+), 34 deletions(-)

--- a/drivers/cpuidle/governors/menu.c
+++ b/drivers/cpuidle/governors/menu.c
@@ -34,7 +34,7 @@
static DEFINE_PER_CPU(struct hrtimer, menu_hrtimer);
static DEFINE_PER_CPU(int, hrtimer_status);
/* menu hrtimer mode */
-enum {MENU_HRTIMER_STOP, MENU_HRTIMER_REPEAT, MENU_HRTIMER_GENERAL};
+enum {MENU_HRTIMER_STOP, MENU_HRTIMER_REPEAT};

/*
* Concepts and ideas behind the menu governor
@@ -116,13 +116,6 @@ enum {MENU_HRTIMER_STOP, MENU_HRTIMER_RE
*
*/

-/*
- * The C-state residency is so long that is is worthwhile to exit
- * from the shallow C-state and re-enter into a deeper C-state.
- */
-static unsigned int perfect_cstate_ms __read_mostly = 30;
-module_param(perfect_cstate_ms, uint, 0000);
-
struct menu_device {
int last_state_idx;
int needs_update;
@@ -223,16 +216,6 @@ EXPORT_SYMBOL_GPL(menu_hrtimer_cancel);
static enum hrtimer_restart menu_hrtimer_notify(struct hrtimer *hrtimer)
{
int cpu = smp_processor_id();
- struct menu_device *data = &per_cpu(menu_devices, cpu);
-
- /* In general case, the expected residency is much larger than
- * deepest C-state target residency, but prediction logic still
- * predicts a small predicted residency, so the prediction
- * history is totally broken if the timer is triggered.
- * So reset the correction factor.
- */
- if (per_cpu(hrtimer_status, cpu) == MENU_HRTIMER_GENERAL)
- data->correction_factor[data->bucket] = RESOLUTION * DECAY;

per_cpu(hrtimer_status, cpu) = MENU_HRTIMER_STOP;

@@ -389,7 +372,6 @@ static int menu_select(struct cpuidle_dr
/* not deepest C-state chosen for low predicted residency */
if (low_predicted) {
unsigned int timer_us = 0;
- unsigned int perfect_us = 0;

/*
* Set a timer to detect whether this sleep is much
@@ -400,28 +382,13 @@ static int menu_select(struct cpuidle_dr
*/
timer_us = 2 * (data->predicted_us + MAX_DEVIATION);

- perfect_us = perfect_cstate_ms * 1000;
-
if (repeat && (4 * timer_us < data->expected_us)) {
RCU_NONIDLE(hrtimer_start(hrtmr,
ns_to_ktime(1000 * timer_us),
HRTIMER_MODE_REL_PINNED));
/* In repeat case, menu hrtimer is started */
per_cpu(hrtimer_status, cpu) = MENU_HRTIMER_REPEAT;
- } else if (perfect_us < data->expected_us) {
- /*
- * The next timer is long. This could be because
- * we did not make a useful prediction.
- * In that case, it makes sense to re-enter
- * into a deeper C-state after some time.
- */
- RCU_NONIDLE(hrtimer_start(hrtmr,
- ns_to_ktime(1000 * timer_us),
- HRTIMER_MODE_REL_PINNED));
- /* In general case, menu hrtimer is started */
- per_cpu(hrtimer_status, cpu) = MENU_HRTIMER_GENERAL;
}
-
}

return data->last_state_idx;

2013-08-09 02:07:45

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 074/102] drm/i915: Preserve the DDI_A_4_LANES bit from the bios

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

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

From: Stéphane Marchesin <[email protected]>

commit bcf53de4e60d9000b82f541d654529e2902a4c2c upstream.

Otherwise the DDI_A_4_LANES bit gets lost and we can't use > 2 lanes
on eDP. This fixes eDP on hsw with > 2 lanes.

Also s/port_reversal/saved_port_bits/ since the current name is
confusing.

Signed-off-by: Stéphane Marchesin <[email protected]>
Reviewed-by: Paulo Zanoni <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Cc: Zhouping Liu <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/gpu/drm/i915/intel_ddi.c | 10 ++++++----
drivers/gpu/drm/i915/intel_drv.h | 2 +-
2 files changed, 7 insertions(+), 5 deletions(-)

--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -684,7 +684,7 @@ static void intel_ddi_mode_set(struct dr
struct intel_digital_port *intel_dig_port =
enc_to_dig_port(encoder);

- intel_dp->DP = intel_dig_port->port_reversal |
+ intel_dp->DP = intel_dig_port->saved_port_bits |
DDI_BUF_CTL_ENABLE | DDI_BUF_EMP_400MV_0DB_HSW;
switch (intel_dp->lane_count) {
case 1:
@@ -1324,7 +1324,8 @@ static void intel_enable_ddi(struct inte
* enabling the port.
*/
I915_WRITE(DDI_BUF_CTL(port),
- intel_dig_port->port_reversal | DDI_BUF_CTL_ENABLE);
+ intel_dig_port->saved_port_bits |
+ DDI_BUF_CTL_ENABLE);
} else if (type == INTEL_OUTPUT_EDP) {
struct intel_dp *intel_dp = enc_to_intel_dp(encoder);

@@ -1543,8 +1544,9 @@ void intel_ddi_init(struct drm_device *d
intel_encoder->get_hw_state = intel_ddi_get_hw_state;

intel_dig_port->port = port;
- intel_dig_port->port_reversal = I915_READ(DDI_BUF_CTL(port)) &
- DDI_BUF_PORT_REVERSAL;
+ intel_dig_port->saved_port_bits = I915_READ(DDI_BUF_CTL(port)) &
+ (DDI_BUF_PORT_REVERSAL |
+ DDI_A_4_LANES);
if (hdmi_connector)
intel_dig_port->hdmi.hdmi_reg = DDI_BUF_CTL(port);
intel_dig_port->dp.output_reg = DDI_BUF_CTL(port);
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -426,7 +426,7 @@ struct intel_dp {
struct intel_digital_port {
struct intel_encoder base;
enum port port;
- u32 port_reversal;
+ u32 saved_port_bits;
struct intel_dp dp;
struct intel_hdmi hdmi;
};

2013-08-09 02:07:52

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 069/102] Revert "cpuidle: Quickly notice prediction failure for repeat mode"

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

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

From: "Rafael J. Wysocki" <[email protected]>

commit 148519120c6d1f19ad53349683aeae9f228b0b8d upstream.

Revert commit 69a37bea (cpuidle: Quickly notice prediction failure for
repeat mode), because it has been identified as the source of a
significant performance regression in v3.8 and later as explained by
Jeremy Eder:

We believe we've identified a particular commit to the cpuidle code
that seems to be impacting performance of variety of workloads.
The simplest way to reproduce is using netperf TCP_RR test, so
we're using that, on a pair of Sandy Bridge based servers. We also
have data from a large database setup where performance is also
measurably/positively impacted, though that test data isn't easily
share-able.

Included below are test results from 3 test kernels:

kernel reverts
-----------------------------------------------------------
1) vanilla upstream (no reverts)

2) perfteam2 reverts e11538d1f03914eb92af5a1a378375c05ae8520c

3) test reverts 69a37beabf1f0a6705c08e879bdd5d82ff6486c4
e11538d1f03914eb92af5a1a378375c05ae8520c

In summary, netperf TCP_RR numbers improve by approximately 4%
after reverting 69a37beabf1f0a6705c08e879bdd5d82ff6486c4. When
69a37beabf1f0a6705c08e879bdd5d82ff6486c4 is included, C0 residency
never seems to get above 40%. Taking that patch out gets C0 near
100% quite often, and performance increases.

The below data are histograms representing the %c0 residency @
1-second sample rates (using turbostat), while under netperf test.

- If you look at the first 4 histograms, you can see %c0 residency
almost entirely in the 30,40% bin.
- The last pair, which reverts 69a37beabf1f0a6705c08e879bdd5d82ff6486c4,
shows %c0 in the 80,90,100% bins.

Below each kernel name are netperf TCP_RR trans/s numbers for the
particular kernel that can be disclosed publicly, comparing the 3
test kernels. We ran a 4th test with the vanilla kernel where
we've also set /dev/cpu_dma_latency=0 to show overall impact
boosting single-threaded TCP_RR performance over 11% above
baseline.

3.10-rc2 vanilla RX + c0 lock (/dev/cpu_dma_latency=0):
TCP_RR trans/s 54323.78

-----------------------------------------------------------
3.10-rc2 vanilla RX (no reverts)
TCP_RR trans/s 48192.47

Receiver %c0
0.0000 - 10.0000 [ 1]: *
10.0000 - 20.0000 [ 0]:
20.0000 - 30.0000 [ 0]:
30.0000 - 40.0000 [ 59]:
***********************************************************
40.0000 - 50.0000 [ 1]: *
50.0000 - 60.0000 [ 0]:
60.0000 - 70.0000 [ 0]:
70.0000 - 80.0000 [ 0]:
80.0000 - 90.0000 [ 0]:
90.0000 - 100.0000 [ 0]:

Sender %c0
0.0000 - 10.0000 [ 1]: *
10.0000 - 20.0000 [ 0]:
20.0000 - 30.0000 [ 0]:
30.0000 - 40.0000 [ 11]: ***********
40.0000 - 50.0000 [ 49]:
*************************************************
50.0000 - 60.0000 [ 0]:
60.0000 - 70.0000 [ 0]:
70.0000 - 80.0000 [ 0]:
80.0000 - 90.0000 [ 0]:
90.0000 - 100.0000 [ 0]:

-----------------------------------------------------------
3.10-rc2 perfteam2 RX (reverts commit
e11538d1f03914eb92af5a1a378375c05ae8520c)
TCP_RR trans/s 49698.69

Receiver %c0
0.0000 - 10.0000 [ 1]: *
10.0000 - 20.0000 [ 1]: *
20.0000 - 30.0000 [ 0]:
30.0000 - 40.0000 [ 59]:
***********************************************************
40.0000 - 50.0000 [ 0]:
50.0000 - 60.0000 [ 0]:
60.0000 - 70.0000 [ 0]:
70.0000 - 80.0000 [ 0]:
80.0000 - 90.0000 [ 0]:
90.0000 - 100.0000 [ 0]:

Sender %c0
0.0000 - 10.0000 [ 1]: *
10.0000 - 20.0000 [ 0]:
20.0000 - 30.0000 [ 0]:
30.0000 - 40.0000 [ 2]: **
40.0000 - 50.0000 [ 58]:
**********************************************************
50.0000 - 60.0000 [ 0]:
60.0000 - 70.0000 [ 0]:
70.0000 - 80.0000 [ 0]:
80.0000 - 90.0000 [ 0]:
90.0000 - 100.0000 [ 0]:

-----------------------------------------------------------
3.10-rc2 test RX (reverts 69a37beabf1f0a6705c08e879bdd5d82ff6486c4
and e11538d1f03914eb92af5a1a378375c05ae8520c)
TCP_RR trans/s 47766.95

Receiver %c0
0.0000 - 10.0000 [ 1]: *
10.0000 - 20.0000 [ 1]: *
20.0000 - 30.0000 [ 0]:
30.0000 - 40.0000 [ 27]: ***************************
40.0000 - 50.0000 [ 2]: **
50.0000 - 60.0000 [ 0]:
60.0000 - 70.0000 [ 2]: **
70.0000 - 80.0000 [ 0]:
80.0000 - 90.0000 [ 0]:
90.0000 - 100.0000 [ 28]: ****************************

Sender:
0.0000 - 10.0000 [ 1]: *
10.0000 - 20.0000 [ 0]:
20.0000 - 30.0000 [ 0]:
30.0000 - 40.0000 [ 11]: ***********
40.0000 - 50.0000 [ 0]:
50.0000 - 60.0000 [ 1]: *
60.0000 - 70.0000 [ 0]:
70.0000 - 80.0000 [ 3]: ***
80.0000 - 90.0000 [ 7]: *******
90.0000 - 100.0000 [ 38]: **************************************

These results demonstrate gaining back the tendency of the CPU to
stay in more responsive, performant C-states (and thus yield
measurably better performance), by reverting commit
69a37beabf1f0a6705c08e879bdd5d82ff6486c4.

Requested-by: Jeremy Eder <[email protected]>
Tested-by: Len Brown <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/cpuidle/governors/menu.c | 73 ++-------------------------------------
include/linux/tick.h | 6 ---
kernel/time/tick-sched.c | 9 +---
3 files changed, 6 insertions(+), 82 deletions(-)

--- a/drivers/cpuidle/governors/menu.c
+++ b/drivers/cpuidle/governors/menu.c
@@ -28,13 +28,6 @@
#define MAX_INTERESTING 50000
#define STDDEV_THRESH 400

-/* 60 * 60 > STDDEV_THRESH * INTERVALS = 400 * 8 */
-#define MAX_DEVIATION 60
-
-static DEFINE_PER_CPU(struct hrtimer, menu_hrtimer);
-static DEFINE_PER_CPU(int, hrtimer_status);
-/* menu hrtimer mode */
-enum {MENU_HRTIMER_STOP, MENU_HRTIMER_REPEAT};

/*
* Concepts and ideas behind the menu governor
@@ -198,42 +191,17 @@ static u64 div_round64(u64 dividend, u32
return div_u64(dividend + (divisor / 2), divisor);
}

-/* Cancel the hrtimer if it is not triggered yet */
-void menu_hrtimer_cancel(void)
-{
- int cpu = smp_processor_id();
- struct hrtimer *hrtmr = &per_cpu(menu_hrtimer, cpu);
-
- /* The timer is still not time out*/
- if (per_cpu(hrtimer_status, cpu)) {
- hrtimer_cancel(hrtmr);
- per_cpu(hrtimer_status, cpu) = MENU_HRTIMER_STOP;
- }
-}
-EXPORT_SYMBOL_GPL(menu_hrtimer_cancel);
-
-/* Call back for hrtimer is triggered */
-static enum hrtimer_restart menu_hrtimer_notify(struct hrtimer *hrtimer)
-{
- int cpu = smp_processor_id();
-
- per_cpu(hrtimer_status, cpu) = MENU_HRTIMER_STOP;
-
- return HRTIMER_NORESTART;
-}
-
/*
* Try detecting repeating patterns by keeping track of the last 8
* intervals, and checking if the standard deviation of that set
* of points is below a threshold. If it is... then use the
* average of these 8 points as the estimated value.
*/
-static u32 get_typical_interval(struct menu_device *data)
+static void get_typical_interval(struct menu_device *data)
{
int i = 0, divisor = 0;
uint64_t max = 0, avg = 0, stddev = 0;
int64_t thresh = LLONG_MAX; /* Discard outliers above this value. */
- unsigned int ret = 0;

again:

@@ -274,16 +242,13 @@ again:
if (((avg > stddev * 6) && (divisor * 4 >= INTERVALS * 3))
|| stddev <= 20) {
data->predicted_us = avg;
- ret = 1;
- return ret;
+ return;

} else if ((divisor * 4) > INTERVALS * 3) {
/* Exclude the max interval */
thresh = max - 1;
goto again;
}
-
- return ret;
}

/**
@@ -298,9 +263,6 @@ static int menu_select(struct cpuidle_dr
int i;
int multiplier;
struct timespec t;
- int repeat = 0, low_predicted = 0;
- int cpu = smp_processor_id();
- struct hrtimer *hrtmr = &per_cpu(menu_hrtimer, cpu);

if (data->needs_update) {
menu_update(drv, dev);
@@ -335,7 +297,7 @@ static int menu_select(struct cpuidle_dr
data->predicted_us = div_round64(data->expected_us * data->correction_factor[data->bucket],
RESOLUTION * DECAY);

- repeat = get_typical_interval(data);
+ get_typical_interval(data);

/*
* We want to default to C1 (hlt), not to busy polling
@@ -356,10 +318,8 @@ static int menu_select(struct cpuidle_dr

if (s->disabled || su->disable)
continue;
- if (s->target_residency > data->predicted_us) {
- low_predicted = 1;
+ if (s->target_residency > data->predicted_us)
continue;
- }
if (s->exit_latency > latency_req)
continue;
if (s->exit_latency * multiplier > data->predicted_us)
@@ -369,28 +329,6 @@ static int menu_select(struct cpuidle_dr
data->exit_us = s->exit_latency;
}

- /* not deepest C-state chosen for low predicted residency */
- if (low_predicted) {
- unsigned int timer_us = 0;
-
- /*
- * Set a timer to detect whether this sleep is much
- * longer than repeat mode predicted. If the timer
- * triggers, the code will evaluate whether to put
- * the CPU into a deeper C-state.
- * The timer is cancelled on CPU wakeup.
- */
- timer_us = 2 * (data->predicted_us + MAX_DEVIATION);
-
- if (repeat && (4 * timer_us < data->expected_us)) {
- RCU_NONIDLE(hrtimer_start(hrtmr,
- ns_to_ktime(1000 * timer_us),
- HRTIMER_MODE_REL_PINNED));
- /* In repeat case, menu hrtimer is started */
- per_cpu(hrtimer_status, cpu) = MENU_HRTIMER_REPEAT;
- }
- }
-
return data->last_state_idx;
}

@@ -481,9 +419,6 @@ static int menu_enable_device(struct cpu
struct cpuidle_device *dev)
{
struct menu_device *data = &per_cpu(menu_devices, dev->cpu);
- struct hrtimer *t = &per_cpu(menu_hrtimer, dev->cpu);
- hrtimer_init(t, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
- t->function = menu_hrtimer_notify;

memset(data, 0, sizeof(struct menu_device));

--- a/include/linux/tick.h
+++ b/include/linux/tick.h
@@ -174,10 +174,4 @@ static inline void tick_nohz_task_switch
#endif


-# ifdef CONFIG_CPU_IDLE_GOV_MENU
-extern void menu_hrtimer_cancel(void);
-# else
-static inline void menu_hrtimer_cancel(void) {}
-# endif /* CONFIG_CPU_IDLE_GOV_MENU */
-
#endif
--- a/kernel/time/tick-sched.c
+++ b/kernel/time/tick-sched.c
@@ -832,13 +832,10 @@ void tick_nohz_irq_exit(void)
{
struct tick_sched *ts = &__get_cpu_var(tick_cpu_sched);

- if (ts->inidle) {
- /* Cancel the timer because CPU already waken up from the C-states*/
- menu_hrtimer_cancel();
+ if (ts->inidle)
__tick_nohz_idle_enter(ts);
- } else {
+ else
tick_nohz_full_stop_tick(ts);
- }
}

/**
@@ -936,8 +933,6 @@ void tick_nohz_idle_exit(void)

ts->inidle = 0;

- /* Cancel the timer because CPU already waken up from the C-states*/
- menu_hrtimer_cancel();
if (ts->idle_active || ts->tick_stopped)
now = ktime_get();


2013-08-09 02:07:50

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 070/102] PCI: pciehp: Fix null pointer deref when hot-removing SR-IOV device

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

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

From: Yinghai Lu <[email protected]>

commit 29ed1f29b68a8395d5679b3c4e38352b617b3236 upstream.

Hot-removing a device with SR-IOV enabled causes a null pointer dereference
in v3.9 and v3.10.

This is a regression caused by ba518e3c17 ("PCI: pciehp: Iterate over all
devices in slot, not functions 0-7"). When we iterate over the
bus->devices list, we first remove the PF, which also removes all the VFs
from the list. Then the list iterator blows up because more than just the
current entry was removed from the list.

ac205b7bb7 ("PCI: make sriov work with hotplug remove") works around a
similar problem in pci_stop_bus_devices() by iterating over the list in
reverse, so the VFs are stopped and removed from the list first, before the
PF.

This patch changes pciehp_unconfigure_device() to iterate over the list in
reverse, too.

[bhelgaas: bugzilla, changelog]
Reference: https://bugzilla.kernel.org/show_bug.cgi?id=60604
Signed-off-by: Yinghai Lu <[email protected]>
Signed-off-by: Bjorn Helgaas <[email protected]>
Acked-by: Yijing Wang <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/pci/hotplug/pciehp_pci.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)

--- a/drivers/pci/hotplug/pciehp_pci.c
+++ b/drivers/pci/hotplug/pciehp_pci.c
@@ -92,7 +92,14 @@ int pciehp_unconfigure_device(struct slo
if (ret)
presence = 0;

- list_for_each_entry_safe(dev, temp, &parent->devices, bus_list) {
+ /*
+ * Stopping an SR-IOV PF device removes all the associated VFs,
+ * which will update the bus->devices list and confuse the
+ * iterator. Therefore, iterate in reverse so we remove the VFs
+ * first, then the PF. We do the same in pci_stop_bus_device().
+ */
+ list_for_each_entry_safe_reverse(dev, temp, &parent->devices,
+ bus_list) {
pci_dev_get(dev);
if (dev->hdr_type == PCI_HEADER_TYPE_BRIDGE && presence) {
pci_read_config_byte(dev, PCI_BRIDGE_CONTROL, &bctl);

2013-08-09 02:07:48

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 073/102] xen-blkfront: use a different scatterlist for each request

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

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

From: Roger Pau Monne <[email protected]>

commit b7649158a0d241f8d53d13ff7441858539e16656 upstream.

In blkif_queue_request blkfront iterates over the scatterlist in order
to set the segments of the request, and in blkif_completion blkfront
iterates over the raw request, which makes it hard to know the exact
position of the source and destination memory positions.

This can be solved by allocating a scatterlist for each request, that
will be keep until the request is finished, allowing us to copy the
data back to the original memory without having to iterate over the
raw request.

Oracle-Bug: 16660413 - LARGE ASYNCHRONOUS READS APPEAR BROKEN ON 2.6.39-400
CC: [email protected]
Signed-off-by: Roger Pau Monné <[email protected]>
Reported-and-Tested-by: Anne Milicia <[email protected]>
Signed-off-by: Konrad Rzeszutek Wilk <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>


---
drivers/block/xen-blkfront.c | 36 +++++++++++++++++-------------------
1 file changed, 17 insertions(+), 19 deletions(-)

--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -75,6 +75,7 @@ struct blk_shadow {
struct blkif_request req;
struct request *request;
struct grant *grants_used[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+ struct scatterlist sg[BLKIF_MAX_SEGMENTS_PER_REQUEST];
};

static DEFINE_MUTEX(blkfront_mutex);
@@ -98,7 +99,6 @@ struct blkfront_info
enum blkif_state connected;
int ring_ref;
struct blkif_front_ring ring;
- struct scatterlist sg[BLKIF_MAX_SEGMENTS_PER_REQUEST];
unsigned int evtchn, irq;
struct request_queue *rq;
struct work_struct work;
@@ -422,11 +422,11 @@ static int blkif_queue_request(struct re
ring_req->u.discard.flag = 0;
} else {
ring_req->u.rw.nr_segments = blk_rq_map_sg(req->q, req,
- info->sg);
+ info->shadow[id].sg);
BUG_ON(ring_req->u.rw.nr_segments >
BLKIF_MAX_SEGMENTS_PER_REQUEST);

- for_each_sg(info->sg, sg, ring_req->u.rw.nr_segments, i) {
+ for_each_sg(info->shadow[id].sg, sg, ring_req->u.rw.nr_segments, i) {
fsect = sg->offset >> 9;
lsect = fsect + (sg->length >> 9) - 1;

@@ -867,12 +867,12 @@ static void blkif_completion(struct blk_
struct blkif_response *bret)
{
int i = 0;
- struct bio_vec *bvec;
- struct req_iterator iter;
- unsigned long flags;
+ struct scatterlist *sg;
char *bvec_data;
void *shared_data;
- unsigned int offset = 0;
+ int nseg;
+
+ nseg = s->req.u.rw.nr_segments;

if (bret->operation == BLKIF_OP_READ) {
/*
@@ -881,19 +881,16 @@ static void blkif_completion(struct blk_
* than PAGE_SIZE, we have to keep track of the current offset,
* to be sure we are copying the data from the right shared page.
*/
- rq_for_each_segment(bvec, s->request, iter) {
- BUG_ON((bvec->bv_offset + bvec->bv_len) > PAGE_SIZE);
- if (bvec->bv_offset < offset)
- i++;
- BUG_ON(i >= s->req.u.rw.nr_segments);
+ for_each_sg(s->sg, sg, nseg, i) {
+ BUG_ON(sg->offset + sg->length > PAGE_SIZE);
shared_data = kmap_atomic(
pfn_to_page(s->grants_used[i]->pfn));
- bvec_data = bvec_kmap_irq(bvec, &flags);
- memcpy(bvec_data, shared_data + bvec->bv_offset,
- bvec->bv_len);
- bvec_kunmap_irq(bvec_data, &flags);
+ bvec_data = kmap_atomic(sg_page(sg));
+ memcpy(bvec_data + sg->offset,
+ shared_data + sg->offset,
+ sg->length);
+ kunmap_atomic(bvec_data);
kunmap_atomic(shared_data);
- offset = bvec->bv_offset + bvec->bv_len;
}
}
/* Add the persistent grant into the list of free grants */
@@ -1022,7 +1019,7 @@ static int setup_blkring(struct xenbus_d
struct blkfront_info *info)
{
struct blkif_sring *sring;
- int err;
+ int err, i;

info->ring_ref = GRANT_INVALID_REF;

@@ -1034,7 +1031,8 @@ static int setup_blkring(struct xenbus_d
SHARED_RING_INIT(sring);
FRONT_RING_INIT(&info->ring, sring, PAGE_SIZE);

- sg_init_table(info->sg, BLKIF_MAX_SEGMENTS_PER_REQUEST);
+ for (i = 0; i < BLK_RING_SIZE; i++)
+ sg_init_table(info->shadow[i].sg, BLKIF_MAX_SEGMENTS_PER_REQUEST);

/* Allocate memory for grants */
err = fill_grant_buffer(info, BLK_RING_SIZE *

2013-08-09 02:08:52

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 068/102] cpufreq: Fix cpufreq driver module refcount balance after suspend/resume

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

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

From: "Rafael J. Wysocki" <[email protected]>

commit 2a99859932281ed6c2ecdd988855f8f6838f6743 upstream.

Since cpufreq_cpu_put() called by __cpufreq_remove_dev() drops the
driver module refcount, __cpufreq_remove_dev() causes that refcount
to become negative for the cpufreq driver after a suspend/resume
cycle.

This is not the only bad thing that happens there, however, because
kobject_put() should only be called for the policy kobject at this
point if the CPU is not the last one for that policy.

Namely, if the given CPU is the last one for that policy, the
policy kobject's refcount should be 1 at this point, as set by
cpufreq_add_dev_interface(), and only needs to be dropped once for
the kobject to go away. This actually happens under the cpu == 1
check, so it need not be done before by cpufreq_cpu_put().

On the other hand, if the given CPU is not the last one for that
policy, this means that cpufreq_add_policy_cpu() has been called
at least once for that policy and cpufreq_cpu_get() has been
called for it too. To balance that cpufreq_cpu_get(), we need to
call cpufreq_cpu_put() in that case.

Thus, to fix the described problem and keep the reference
counters balanced in both cases, move the cpufreq_cpu_get() call
in __cpufreq_remove_dev() to the code path executed only for
CPUs that share the policy with other CPUs.

Reported-and-tested-by: Toralf Förster <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>
Reviewed-by: Srivatsa S. Bhat <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/cpufreq/cpufreq.c | 19 ++++++++++---------
1 file changed, 10 insertions(+), 9 deletions(-)

--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -1075,14 +1075,11 @@ static int __cpufreq_remove_dev(struct d
__func__, cpu_dev->id, cpu);
}

- if ((cpus == 1) && (cpufreq_driver->target))
- __cpufreq_governor(data, CPUFREQ_GOV_POLICY_EXIT);
-
- pr_debug("%s: removing link, cpu: %d\n", __func__, cpu);
- cpufreq_cpu_put(data);
-
/* If cpu is last user of policy, free policy */
if (cpus == 1) {
+ if (cpufreq_driver->target)
+ __cpufreq_governor(data, CPUFREQ_GOV_POLICY_EXIT);
+
lock_policy_rwsem_read(cpu);
kobj = &data->kobj;
cmp = &data->kobj_unregister;
@@ -1103,9 +1100,13 @@ static int __cpufreq_remove_dev(struct d
free_cpumask_var(data->related_cpus);
free_cpumask_var(data->cpus);
kfree(data);
- } else if (cpufreq_driver->target) {
- __cpufreq_governor(data, CPUFREQ_GOV_START);
- __cpufreq_governor(data, CPUFREQ_GOV_LIMITS);
+ } else {
+ pr_debug("%s: removing link, cpu: %d\n", __func__, cpu);
+ cpufreq_cpu_put(data);
+ if (cpufreq_driver->target) {
+ __cpufreq_governor(data, CPUFREQ_GOV_START);
+ __cpufreq_governor(data, CPUFREQ_GOV_LIMITS);
+ }
}

per_cpu(cpufreq_policy_cpu, cpu) = -1;

2013-08-09 01:59:17

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 057/102] mwifiex: Add missing endian conversion.

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

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

From: Tomasz Moń <[email protected]>

commit 83e612f632c3897be29ef02e0472f6d63e258378 upstream.

Both type and pkt_len variables are in host endian and these should be in
Little Endian in the payload.

Signed-off-by: Tomasz Moń <[email protected]>
Acked-by: Bing Zhao <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/net/wireless/mwifiex/sdio.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/net/wireless/mwifiex/sdio.c
+++ b/drivers/net/wireless/mwifiex/sdio.c
@@ -1441,8 +1441,8 @@ static int mwifiex_sdio_host_to_card(str
/* Allocate buffer and copy payload */
blk_size = MWIFIEX_SDIO_BLOCK_SIZE;
buf_block_len = (pkt_len + blk_size - 1) / blk_size;
- *(u16 *) &payload[0] = (u16) pkt_len;
- *(u16 *) &payload[2] = type;
+ *(__le16 *)&payload[0] = cpu_to_le16((u16)pkt_len);
+ *(__le16 *)&payload[2] = cpu_to_le16(type);

/*
* This is SDIO specific header

2013-08-09 02:09:13

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 059/102] mwifiex: fix wrong data rates in P2P client

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

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

From: Avinash Patil <[email protected]>

commit 237b2ac8ac89a6b0120decdd05c7bf4637deb98a upstream.

This patch fixes an issue wherein adhoc rates were being copied
into association request from P2P client.

Signed-off-by: Avinash Patil <[email protected]>
Signed-off-by: Stone Piao <[email protected]>
Signed-off-by: Bing Zhao <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/net/wireless/mwifiex/cfp.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

--- a/drivers/net/wireless/mwifiex/cfp.c
+++ b/drivers/net/wireless/mwifiex/cfp.c
@@ -415,7 +415,8 @@ u32 mwifiex_get_supported_rates(struct m
u32 k = 0;
struct mwifiex_adapter *adapter = priv->adapter;

- if (priv->bss_mode == NL80211_IFTYPE_STATION) {
+ if (priv->bss_mode == NL80211_IFTYPE_STATION ||
+ priv->bss_mode == NL80211_IFTYPE_P2P_CLIENT) {
switch (adapter->config_bands) {
case BAND_B:
dev_dbg(adapter->dev, "info: infra band=%d "

2013-08-09 02:09:38

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 066/102] ACPI / battery: Fix parsing _BIX return value

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

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

From: Lan Tianyu <[email protected]>

commit 016d5baad04269e8559332df05f89bd95b52d6ad upstream.

The _BIX method returns extended battery info as a package.
According the ACPI spec (ACPI 5, Section 10.2.2.2), the first member
of that package should be "Revision". However, the current ACPI
battery driver treats the first member as "Power Unit" which should
be the second member. This causes the result of _BIX return data
parsing to be incorrect.

Fix this by adding a new member called 'revision' to struct
acpi_battery and adding the offsetof() information on it to
extended_info_offsets[] as the first row.

[rjw: Changelog]
Reported-and-tested-by: Jan Hoffmann <[email protected]>
References: http://bugzilla.kernel.org/show_bug.cgi?id=60519
Signed-off-by: Lan Tianyu <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/acpi/battery.c | 2 ++
1 file changed, 2 insertions(+)

--- a/drivers/acpi/battery.c
+++ b/drivers/acpi/battery.c
@@ -117,6 +117,7 @@ struct acpi_battery {
struct acpi_device *device;
struct notifier_block pm_nb;
unsigned long update_time;
+ int revision;
int rate_now;
int capacity_now;
int voltage_now;
@@ -359,6 +360,7 @@ static struct acpi_offsets info_offsets[
};

static struct acpi_offsets extended_info_offsets[] = {
+ {offsetof(struct acpi_battery, revision), 0},
{offsetof(struct acpi_battery, power_unit), 0},
{offsetof(struct acpi_battery, design_capacity), 0},
{offsetof(struct acpi_battery, full_charge_capacity), 0},

2013-08-09 02:09:55

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 065/102] zram: protect sysfs handler from invalid memory access

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

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

From: Jiang Liu <[email protected]>

commit 5863e10b441e7ea4b492f930f1be180a97d026f3 upstream.

Use zram->init_lock to protect access to zram->meta, otherwise it
may cause invalid memory access if zram->meta has been freed by
zram_reset_device().

This issue may be triggered by:
Thread 1:
while true; do cat mem_used_total; done
Thread 2:
while true; do echo 8M > disksize; echo 1 > reset; done

Signed-off-by: Jiang Liu <[email protected]>
Acked-by: Minchan Kim <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/staging/zram/zram_sysfs.c | 2 ++
1 file changed, 2 insertions(+)

--- a/drivers/staging/zram/zram_sysfs.c
+++ b/drivers/staging/zram/zram_sysfs.c
@@ -188,8 +188,10 @@ static ssize_t mem_used_total_show(struc
struct zram *zram = dev_to_zram(dev);
struct zram_meta *meta = zram->meta;

+ down_read(&zram->init_lock);
if (zram->init_done)
val = zs_get_total_size_bytes(meta->mem_pool);
+ up_read(&zram->init_lock);

return sprintf(buf, "%llu\n", val);
}

2013-08-09 02:10:22

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 063/102] zram: avoid double free in function zram_bvec_write()

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

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

From: Jiang Liu <[email protected]>

commit 65c484609a3b25c35e4edcd5f2c38f98f5226093 upstream.

When doing a patial write and the whole page is filled with zero,
zram_bvec_write() will free uncmem twice.

Signed-off-by: Jiang Liu <[email protected]>
Acked-by: Minchan Kim <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/staging/zram/zram_drv.c | 2 --
1 file changed, 2 deletions(-)

--- a/drivers/staging/zram/zram_drv.c
+++ b/drivers/staging/zram/zram_drv.c
@@ -272,8 +272,6 @@ static int zram_bvec_write(struct zram *

if (page_zero_filled(uncmem)) {
kunmap_atomic(user_mem);
- if (is_partial_io(bvec))
- kfree(uncmem);
zram->stats.pages_zero++;
zram_set_flag(meta, index, ZRAM_ZERO);
ret = 0;

2013-08-09 02:10:46

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 062/102] zram: destroy all devices on error recovery path in zram_init()

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

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

From: Jiang Liu <[email protected]>

commit 39a9b8ac9333e4268ecff7da6c9d1ab3823ff243 upstream.

On error recovery path of zram_init(), it leaks the zram device object
causing the failure. So change create_device() to free allocated
resources on error path.

Signed-off-by: Jiang Liu <[email protected]>
Acked-by: Minchan Kim <[email protected]>
Acked-by: Jerome Marchand <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/staging/zram/zram_drv.c | 15 +++++++++------
1 file changed, 9 insertions(+), 6 deletions(-)

--- a/drivers/staging/zram/zram_drv.c
+++ b/drivers/staging/zram/zram_drv.c
@@ -595,7 +595,7 @@ static const struct block_device_operati

static int create_device(struct zram *zram, int device_id)
{
- int ret = 0;
+ int ret = -ENOMEM;

init_rwsem(&zram->lock);
init_rwsem(&zram->init_lock);
@@ -605,7 +605,6 @@ static int create_device(struct zram *zr
if (!zram->queue) {
pr_err("Error allocating disk queue for device %d\n",
device_id);
- ret = -ENOMEM;
goto out;
}

@@ -615,11 +614,9 @@ static int create_device(struct zram *zr
/* gendisk structure */
zram->disk = alloc_disk(1);
if (!zram->disk) {
- blk_cleanup_queue(zram->queue);
pr_warn("Error allocating disk structure for device %d\n",
device_id);
- ret = -ENOMEM;
- goto out;
+ goto out_free_queue;
}

zram->disk->major = zram_major;
@@ -648,11 +645,17 @@ static int create_device(struct zram *zr
&zram_disk_attr_group);
if (ret < 0) {
pr_warn("Error creating sysfs group");
- goto out;
+ goto out_free_disk;
}

zram->init_done = 0;
+ return 0;

+out_free_disk:
+ del_gendisk(zram->disk);
+ put_disk(zram->disk);
+out_free_queue:
+ blk_cleanup_queue(zram->queue);
out:
return ret;
}

2013-08-09 01:59:12

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 049/102] Bluetooth: Add support for Atheros [0cf3:3121]

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

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

From: AceLan Kao <[email protected]>

commit 1ebd0b21ab14efb75950079840eac29afea2a26e upstream.

Add support for the AR3012 chip.

T: Bus=03 Lev=01 Prnt=01 Port=06 Cnt=01 Dev#= 6 Spd=12 MxCh= 0
D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=0cf3 ProdID=3121 Rev=00.02
C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb

Signed-off-by: AceLan Kao <[email protected]>
Signed-off-by: Gustavo Padovan <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/bluetooth/ath3k.c | 2 ++
drivers/bluetooth/btusb.c | 1 +
2 files changed, 3 insertions(+)

--- a/drivers/bluetooth/ath3k.c
+++ b/drivers/bluetooth/ath3k.c
@@ -93,6 +93,7 @@ static struct usb_device_id ath3k_table[
{ USB_DEVICE(0x0489, 0xe04d) },
{ USB_DEVICE(0x04c5, 0x1330) },
{ USB_DEVICE(0x13d3, 0x3402) },
+ { USB_DEVICE(0x0cf3, 0x3121) },

/* Atheros AR5BBU12 with sflash firmware */
{ USB_DEVICE(0x0489, 0xE02C) },
@@ -132,6 +133,7 @@ static struct usb_device_id ath3k_blist_
{ USB_DEVICE(0x0489, 0xe04d), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x04c5, 0x1330), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x13d3, 0x3402), .driver_info = BTUSB_ATH3012 },
+ { USB_DEVICE(0x0cf3, 0x3121), .driver_info = BTUSB_ATH3012 },

/* Atheros AR5BBU22 with sflash firmware */
{ USB_DEVICE(0x0489, 0xE03C), .driver_info = BTUSB_ATH3012 },
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -153,6 +153,7 @@ static struct usb_device_id blacklist_ta
{ USB_DEVICE(0x0489, 0xe04d), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x04c5, 0x1330), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x13d3, 0x3402), .driver_info = BTUSB_ATH3012 },
+ { USB_DEVICE(0x0cf3, 0x3121), .driver_info = BTUSB_ATH3012 },

/* Atheros AR5BBU12 with sflash firmware */
{ USB_DEVICE(0x0489, 0xe02c), .driver_info = BTUSB_IGNORE },

2013-08-09 02:11:00

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 061/102] zram: use zram->lock to protect zram_free_page() in swap free notify path

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

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

From: Jiang Liu <[email protected]>

commit 57ab048532c0d975538cebd4456491b5c34248f4 upstream.

zram_slot_free_notify() is free-running without any protection from
concurrent operations. So there are race conditions between
zram_bvec_read()/zram_bvec_write() and zram_slot_free_notify(),
and possible consequences include:
1) Trigger BUG_ON(!handle) on zram_bvec_write() side.
2) Access to freed pages on zram_bvec_read() side.
3) Break some fields (bad_compress, good_compress, pages_stored)
in zram->stats if the swap layer makes concurrently call to
zram_slot_free_notify().

So enhance zram_slot_free_notify() to acquire writer lock on zram->lock
before calling zram_free_page().

Signed-off-by: Jiang Liu <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/staging/zram/zram_drv.c | 2 ++
drivers/staging/zram/zram_drv.h | 5 +++--
2 files changed, 5 insertions(+), 2 deletions(-)

--- a/drivers/staging/zram/zram_drv.c
+++ b/drivers/staging/zram/zram_drv.c
@@ -582,7 +582,9 @@ static void zram_slot_free_notify(struct
struct zram *zram;

zram = bdev->bd_disk->private_data;
+ down_write(&zram->lock);
zram_free_page(zram, index);
+ up_write(&zram->lock);
zram_stat64_inc(zram, &zram->stats.notify_free);
}

--- a/drivers/staging/zram/zram_drv.h
+++ b/drivers/staging/zram/zram_drv.h
@@ -93,8 +93,9 @@ struct zram_meta {
struct zram {
struct zram_meta *meta;
spinlock_t stat64_lock; /* protect 64-bit stats */
- struct rw_semaphore lock; /* protect compression buffers and table
- * against concurrent read and writes */
+ struct rw_semaphore lock; /* protect compression buffers, table,
+ * 32bit stat counters against concurrent
+ * notifications, reads and writes */
struct request_queue *queue;
struct gendisk *disk;
int init_done;

2013-08-09 02:11:22

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 060/102] zram: avoid invalid memory access in zram_exit()

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

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

From: Jiang Liu <[email protected]>

commit 6030ea9b35971a4200062f010341ab832e878ac9 upstream.

Memory for zram->disk object may have already been freed after returning
from destroy_device(zram), then it's unsafe for zram_reset_device(zram)
to access zram->disk again.

We can't solve this bug by flipping the order of destroy_device(zram)
and zram_reset_device(zram), that will cause deadlock issues to the
zram sysfs handler.

So fix it by holding an extra reference to zram->disk before calling
destroy_device(zram).

Signed-off-by: Jiang Liu <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/staging/zram/zram_drv.c | 2 ++
1 file changed, 2 insertions(+)

--- a/drivers/staging/zram/zram_drv.c
+++ b/drivers/staging/zram/zram_drv.c
@@ -727,8 +727,10 @@ static void __exit zram_exit(void)
for (i = 0; i < num_devices; i++) {
zram = &zram_devices[i];

+ get_disk(zram->disk);
destroy_device(zram);
zram_reset_device(zram);
+ put_disk(zram->disk);
}

unregister_blkdev(zram_major, "zram");

2013-08-09 02:11:39

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 050/102] Bluetooth: Add support for Atheros [0cf3:e003]

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

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

From: AceLan Kao <[email protected]>

commit 1d5b569ef85d013a775560a90050dc630614c045 upstream.

Add support for the AR9462 chip

T: Bus=02 Lev=02 Prnt=02 Port=04 Cnt=01 Dev#= 4 Spd=12 MxCh= 0
D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=0cf3 ProdID=e003 Rev=00.02
C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb

Signed-off-by: AceLan Kao <[email protected]>
Signed-off-by: Gustavo Padovan <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/bluetooth/ath3k.c | 2 ++
drivers/bluetooth/btusb.c | 1 +
2 files changed, 3 insertions(+)

--- a/drivers/bluetooth/ath3k.c
+++ b/drivers/bluetooth/ath3k.c
@@ -94,6 +94,7 @@ static struct usb_device_id ath3k_table[
{ USB_DEVICE(0x04c5, 0x1330) },
{ USB_DEVICE(0x13d3, 0x3402) },
{ USB_DEVICE(0x0cf3, 0x3121) },
+ { USB_DEVICE(0x0cf3, 0xe003) },

/* Atheros AR5BBU12 with sflash firmware */
{ USB_DEVICE(0x0489, 0xE02C) },
@@ -134,6 +135,7 @@ static struct usb_device_id ath3k_blist_
{ USB_DEVICE(0x04c5, 0x1330), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x13d3, 0x3402), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0cf3, 0x3121), .driver_info = BTUSB_ATH3012 },
+ { USB_DEVICE(0x0cf3, 0xe003), .driver_info = BTUSB_ATH3012 },

/* Atheros AR5BBU22 with sflash firmware */
{ USB_DEVICE(0x0489, 0xE03C), .driver_info = BTUSB_ATH3012 },
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -154,6 +154,7 @@ static struct usb_device_id blacklist_ta
{ USB_DEVICE(0x04c5, 0x1330), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x13d3, 0x3402), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0cf3, 0x3121), .driver_info = BTUSB_ATH3012 },
+ { USB_DEVICE(0x0cf3, 0xe003), .driver_info = BTUSB_ATH3012 },

/* Atheros AR5BBU12 with sflash firmware */
{ USB_DEVICE(0x0489, 0xe02c), .driver_info = BTUSB_IGNORE },

2013-08-09 02:11:54

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 058/102] mwifiex: check for bss_role instead of bss_mode for STA operations

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

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

From: Avinash Patil <[email protected]>

commit 953b3539ef9301b8ef73f4b6e2fd824b86aae65a upstream.

This patch fixes an issue wherein association would fail on P2P
interfaces. This happened because we are checking priv->mode
against NL80211_IFTYPE_STATION. While this check is correct for
infrastructure stations, it would fail P2P clients for which mode
is NL80211_IFTYPE_P2P_CLIENT.

Better check would be bss_role which has only 2 values: STA/AP.

Signed-off-by: Avinash Patil <[email protected]>
Signed-off-by: Stone Piao <[email protected]>
Signed-off-by: Bing Zhao <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/net/wireless/mwifiex/cfg80211.c | 4 ++--
drivers/net/wireless/mwifiex/join.c | 6 ++++--
2 files changed, 6 insertions(+), 4 deletions(-)

--- a/drivers/net/wireless/mwifiex/cfg80211.c
+++ b/drivers/net/wireless/mwifiex/cfg80211.c
@@ -1668,9 +1668,9 @@ mwifiex_cfg80211_connect(struct wiphy *w
struct mwifiex_private *priv = mwifiex_netdev_get_priv(dev);
int ret;

- if (priv->bss_mode != NL80211_IFTYPE_STATION) {
+ if (GET_BSS_ROLE(priv) != MWIFIEX_BSS_ROLE_STA) {
wiphy_err(wiphy,
- "%s: reject infra assoc request in non-STA mode\n",
+ "%s: reject infra assoc request in non-STA role\n",
dev->name);
return -EINVAL;
}
--- a/drivers/net/wireless/mwifiex/join.c
+++ b/drivers/net/wireless/mwifiex/join.c
@@ -1290,8 +1290,10 @@ int mwifiex_associate(struct mwifiex_pri
{
u8 current_bssid[ETH_ALEN];

- /* Return error if the adapter or table entry is not marked as infra */
- if ((priv->bss_mode != NL80211_IFTYPE_STATION) ||
+ /* Return error if the adapter is not STA role or table entry
+ * is not marked as infra.
+ */
+ if ((GET_BSS_ROLE(priv) != MWIFIEX_BSS_ROLE_STA) ||
(bss_desc->bss_mode != NL80211_IFTYPE_STATION))
return -1;


2013-08-09 01:59:08

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 048/102] Bluetooth: ath3k: Add support for ID 0x13d3/0x3402

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

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

From: Sujith Manoharan <[email protected]>

commit 5b77a1f3d7b7360dc2b7c6d2188d39b9f8432907 upstream.

T: Bus=01 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#= 5 Spd=12 MxCh= 0
D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=13d3 ProdID=3402 Rev= 0.02
S: Manufacturer=Atheros Communications
S: Product=Bluetooth USB Host Controller
S: SerialNumber=Alaska Day 2006
C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb

Bug: https://bugzilla.kernel.org/show_bug.cgi?id=59701

Signed-off-by: Sujith Manoharan <[email protected]>
Signed-off-by: Gustavo Padovan <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/bluetooth/ath3k.c | 2 ++
drivers/bluetooth/btusb.c | 1 +
2 files changed, 3 insertions(+)

--- a/drivers/bluetooth/ath3k.c
+++ b/drivers/bluetooth/ath3k.c
@@ -92,6 +92,7 @@ static struct usb_device_id ath3k_table[
{ USB_DEVICE(0x0489, 0xe056) },
{ USB_DEVICE(0x0489, 0xe04d) },
{ USB_DEVICE(0x04c5, 0x1330) },
+ { USB_DEVICE(0x13d3, 0x3402) },

/* Atheros AR5BBU12 with sflash firmware */
{ USB_DEVICE(0x0489, 0xE02C) },
@@ -130,6 +131,7 @@ static struct usb_device_id ath3k_blist_
{ USB_DEVICE(0x0489, 0xe056), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0489, 0xe04d), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x04c5, 0x1330), .driver_info = BTUSB_ATH3012 },
+ { USB_DEVICE(0x13d3, 0x3402), .driver_info = BTUSB_ATH3012 },

/* Atheros AR5BBU22 with sflash firmware */
{ USB_DEVICE(0x0489, 0xE03C), .driver_info = BTUSB_ATH3012 },
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -152,6 +152,7 @@ static struct usb_device_id blacklist_ta
{ USB_DEVICE(0x0489, 0xe056), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0489, 0xe04d), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x04c5, 0x1330), .driver_info = BTUSB_ATH3012 },
+ { USB_DEVICE(0x13d3, 0x3402), .driver_info = BTUSB_ATH3012 },

/* Atheros AR5BBU12 with sflash firmware */
{ USB_DEVICE(0x0489, 0xe02c), .driver_info = BTUSB_IGNORE },

2013-08-09 02:12:12

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 056/102] rt2x00: fix stop queue

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

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

From: Stanislaw Gruszka <[email protected]>

commit e2288b66fe7ff0288382b2af671b4da558b44472 upstream.

Since we clear QUEUE_STARTED in rt2x00queue_stop_queue(), following
call to rt2x00queue_pause_queue() reduce to noop, i.e we do not
stop queue in mac80211.

To fix that introduce rt2x00queue_pause_queue_nocheck() function,
which will stop queue in mac80211 directly.

Note that rt2x00_start_queue() explicitly set QUEUE_PAUSED bit.

Note also that reordering operations i.e. first call to
rt2x00queue_pause_queue() and then clear QUEUE_STARTED bit, will race
with rt2x00queue_unpause_queue(), so calling ieee80211_stop_queue()
directly is the only available solution to fix the problem without
major rework.

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/rt2x00/rt2x00queue.c | 18 +++++++++++-------
1 file changed, 11 insertions(+), 7 deletions(-)

--- a/drivers/net/wireless/rt2x00/rt2x00queue.c
+++ b/drivers/net/wireless/rt2x00/rt2x00queue.c
@@ -936,13 +936,8 @@ void rt2x00queue_index_inc(struct queue_
spin_unlock_irqrestore(&queue->index_lock, irqflags);
}

-void rt2x00queue_pause_queue(struct data_queue *queue)
+void rt2x00queue_pause_queue_nocheck(struct data_queue *queue)
{
- if (!test_bit(DEVICE_STATE_PRESENT, &queue->rt2x00dev->flags) ||
- !test_bit(QUEUE_STARTED, &queue->flags) ||
- test_and_set_bit(QUEUE_PAUSED, &queue->flags))
- return;
-
switch (queue->qid) {
case QID_AC_VO:
case QID_AC_VI:
@@ -958,6 +953,15 @@ void rt2x00queue_pause_queue(struct data
break;
}
}
+void rt2x00queue_pause_queue(struct data_queue *queue)
+{
+ if (!test_bit(DEVICE_STATE_PRESENT, &queue->rt2x00dev->flags) ||
+ !test_bit(QUEUE_STARTED, &queue->flags) ||
+ test_and_set_bit(QUEUE_PAUSED, &queue->flags))
+ return;
+
+ rt2x00queue_pause_queue_nocheck(queue);
+}
EXPORT_SYMBOL_GPL(rt2x00queue_pause_queue);

void rt2x00queue_unpause_queue(struct data_queue *queue)
@@ -1019,7 +1023,7 @@ void rt2x00queue_stop_queue(struct data_
return;
}

- rt2x00queue_pause_queue(queue);
+ rt2x00queue_pause_queue_nocheck(queue);

queue->rt2x00dev->ops->lib->stop_queue(queue);


2013-08-09 02:12:35

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 055/102] svcrpc: fix kfree oops in gss-proxy code

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

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

From: "J. Bruce Fields" <[email protected]>

commit 743e217129f69aab074abe520a464fd0c6b1cca1 upstream.

mech_oid.data is an array, not kmalloc()'d memory.

Signed-off-by: J. Bruce Fields <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
net/sunrpc/auth_gss/gss_rpc_upcall.c | 1 -
1 file changed, 1 deletion(-)

--- a/net/sunrpc/auth_gss/gss_rpc_upcall.c
+++ b/net/sunrpc/auth_gss/gss_rpc_upcall.c
@@ -328,7 +328,6 @@ void gssp_free_upcall_data(struct gssp_u
kfree(data->in_handle.data);
kfree(data->out_handle.data);
kfree(data->out_token.data);
- kfree(data->mech_oid.data);
free_svc_cred(&data->creds);
}


2013-08-09 02:12:56

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 054/102] svcrpc: fix gss_rpc_upcall create error

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

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

From: "J. Bruce Fields" <[email protected]>

commit 9f96392b0ae6aefc02a9b900c3f4889dfafc8402 upstream.

Signed-off-by: J. Bruce Fields <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
net/sunrpc/auth_gss/gss_rpc_upcall.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/net/sunrpc/auth_gss/gss_rpc_upcall.c
+++ b/net/sunrpc/auth_gss/gss_rpc_upcall.c
@@ -120,7 +120,7 @@ static int gssp_rpc_create(struct net *n
if (IS_ERR(clnt)) {
dprintk("RPC: failed to create AF_LOCAL gssproxy "
"client (errno %ld).\n", PTR_ERR(clnt));
- result = -PTR_ERR(clnt);
+ result = PTR_ERR(clnt);
*_clnt = NULL;
goto out;
}

2013-08-09 01:59:05

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 047/102] Bluetooth: ath3k: dont use stack memory for DMA

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

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

From: Stanislaw Gruszka <[email protected]>

commit 517828a87994f41af6ae5a0f96f0f069f05baa81 upstream.

Memory allocated by vmalloc (including stack) can not be used for DMA,
i.e. data pointer on usb_control_msg() should not point to stack memory.

Resolves:
https://bugzilla.redhat.com/show_bug.cgi?id=977558

Reported-and-tested-by: Andy Lawrence <[email protected]>
Signed-off-by: Stanislaw Gruszka <[email protected]>
Signed-off-by: Gustavo Padovan <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/bluetooth/ath3k.c | 38 +++++++++++++++++++++++++++++---------
1 file changed, 29 insertions(+), 9 deletions(-)

--- a/drivers/bluetooth/ath3k.c
+++ b/drivers/bluetooth/ath3k.c
@@ -195,24 +195,44 @@ error:

static int ath3k_get_state(struct usb_device *udev, unsigned char *state)
{
- int pipe = 0;
+ int ret, pipe = 0;
+ char *buf;
+
+ buf = kmalloc(sizeof(*buf), GFP_KERNEL);
+ if (!buf)
+ return -ENOMEM;

pipe = usb_rcvctrlpipe(udev, 0);
- return usb_control_msg(udev, pipe, ATH3K_GETSTATE,
- USB_TYPE_VENDOR | USB_DIR_IN, 0, 0,
- state, 0x01, USB_CTRL_SET_TIMEOUT);
+ ret = usb_control_msg(udev, pipe, ATH3K_GETSTATE,
+ USB_TYPE_VENDOR | USB_DIR_IN, 0, 0,
+ buf, sizeof(*buf), USB_CTRL_SET_TIMEOUT);
+
+ *state = *buf;
+ kfree(buf);
+
+ return ret;
}

static int ath3k_get_version(struct usb_device *udev,
struct ath3k_version *version)
{
- int pipe = 0;
+ int ret, pipe = 0;
+ struct ath3k_version *buf;
+ const int size = sizeof(*buf);
+
+ buf = kmalloc(size, GFP_KERNEL);
+ if (!buf)
+ return -ENOMEM;

pipe = usb_rcvctrlpipe(udev, 0);
- return usb_control_msg(udev, pipe, ATH3K_GETVERSION,
- USB_TYPE_VENDOR | USB_DIR_IN, 0, 0, version,
- sizeof(struct ath3k_version),
- USB_CTRL_SET_TIMEOUT);
+ ret = usb_control_msg(udev, pipe, ATH3K_GETVERSION,
+ USB_TYPE_VENDOR | USB_DIR_IN, 0, 0,
+ buf, size, USB_CTRL_SET_TIMEOUT);
+
+ memcpy(version, buf, size);
+ kfree(buf);
+
+ return ret;
}

static int ath3k_load_fwfile(struct usb_device *udev,

2013-08-09 02:13:17

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 052/102] Bluetooth: fix wrong use of PTR_ERR() in btusb

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

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

From: Adam Lee <[email protected]>

commit d9c78e9738ccd0017b10b8f44462aafb61904a4a upstream.

PTR_ERR() returns a signed long type value which is limited by IS_ERR(),
it must be a negative number whose range is [-MAX_ERRNO, 0).

The bug here returns negative numbers as error codes, then check it by
"if (ret < 0)", but -PTR_ERR() is actually positive. The wrong use here
leads to failure as below, even panic.

[ 12.958920] Bluetooth: hci0 command 0xfc8e tx timeout
[ 14.961765] Bluetooth: hci0 command 0xfc8e tx timeout
[ 16.964688] Bluetooth: hci0 command 0xfc8e tx timeout
[ 20.954501] Bluetooth: hci0 sending Intel patch command (0xfc8e) failed (-110)
[ 22.957358] Bluetooth: hci0 command 0xfc8e tx timeout
[ 30.948922] Bluetooth: hci0 sending Intel patch command (0xfc8e) failed (-110)
[ 32.951780] Bluetooth: hci0 command 0xfc8e tx timeout
[ 40.943359] Bluetooth: hci0 sending Intel patch command (0xfc8e) failed (-110)
[ 42.946219] Bluetooth: hci0 command 0xfc8e tx timeout
[ 50.937812] Bluetooth: hci0 sending Intel patch command (0xfc8e) failed (-110)
[ 52.940670] Bluetooth: hci0 command 0xfc8e tx timeout
[ 60.932236] Bluetooth: hci0 sending Intel patch command (0xfc8e) failed (-110)
[ 62.935092] Bluetooth: hci0 command 0xfc8e tx timeout
[ 70.926688] Bluetooth: hci0 sending Intel patch command (0xfc8e) failed (-110)
[ 72.929545] Bluetooth: hci0 command 0xfc8e tx timeout
[ 80.921111] Bluetooth: hci0 sending Intel patch command (0xfc8e) failed (-110)
[ 82.923969] Bluetooth: hci0 command 0xfc2f tx timeout
[ 90.915542] Bluetooth: hci0 sending Intel patch command (0xfc2f) failed (-110)
[ 92.918406] Bluetooth: hci0 command 0xfc11 tx timeout
[ 100.909955] Bluetooth: hci0 sending Intel patch command (0xfc11) failed (-110)
[ 102.912858] Bluetooth: hci0 command 0xfc60 tx timeout
[ 110.904394] Bluetooth: hci0 sending Intel patch command (0xfc60) failed (-110)
[ 112.907293] Bluetooth: hci0 command 0xfc11 tx timeout
[ 120.898831] Bluetooth: hci0 exiting Intel manufacturer mode failed (-110)
[ 120.904757] bluetoothd[1030]: segfault at 4 ip 00007f8b2eb55236 sp 00007fff53ff6920 error 4 in bluetoothd[7f8b2eaff000+cb000]

Signed-off-by: Adam Lee <[email protected]>
Signed-off-by: Gustavo Padovan <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/bluetooth/btusb.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)

--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -1099,7 +1099,7 @@ static int btusb_setup_intel_patching(st
if (IS_ERR(skb)) {
BT_ERR("%s sending Intel patch command (0x%4.4x) failed (%ld)",
hdev->name, cmd->opcode, PTR_ERR(skb));
- return -PTR_ERR(skb);
+ return PTR_ERR(skb);
}

/* It ensures that the returned event matches the event data read from
@@ -1151,7 +1151,7 @@ static int btusb_setup_intel(struct hci_
if (IS_ERR(skb)) {
BT_ERR("%s sending initial HCI reset command failed (%ld)",
hdev->name, PTR_ERR(skb));
- return -PTR_ERR(skb);
+ return PTR_ERR(skb);
}
kfree_skb(skb);

@@ -1165,7 +1165,7 @@ static int btusb_setup_intel(struct hci_
if (IS_ERR(skb)) {
BT_ERR("%s reading Intel fw version command failed (%ld)",
hdev->name, PTR_ERR(skb));
- return -PTR_ERR(skb);
+ return PTR_ERR(skb);
}

if (skb->len != sizeof(*ver)) {
@@ -1223,7 +1223,7 @@ static int btusb_setup_intel(struct hci_
BT_ERR("%s entering Intel manufacturer mode failed (%ld)",
hdev->name, PTR_ERR(skb));
release_firmware(fw);
- return -PTR_ERR(skb);
+ return PTR_ERR(skb);
}

if (skb->data[0]) {
@@ -1280,7 +1280,7 @@ static int btusb_setup_intel(struct hci_
if (IS_ERR(skb)) {
BT_ERR("%s exiting Intel manufacturer mode failed (%ld)",
hdev->name, PTR_ERR(skb));
- return -PTR_ERR(skb);
+ return PTR_ERR(skb);
}
kfree_skb(skb);

@@ -1296,7 +1296,7 @@ exit_mfg_disable:
if (IS_ERR(skb)) {
BT_ERR("%s exiting Intel manufacturer mode failed (%ld)",
hdev->name, PTR_ERR(skb));
- return -PTR_ERR(skb);
+ return PTR_ERR(skb);
}
kfree_skb(skb);

@@ -1314,7 +1314,7 @@ exit_mfg_deactivate:
if (IS_ERR(skb)) {
BT_ERR("%s exiting Intel manufacturer mode failed (%ld)",
hdev->name, PTR_ERR(skb));
- return -PTR_ERR(skb);
+ return PTR_ERR(skb);
}
kfree_skb(skb);


2013-08-09 02:13:38

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 051/102] Bluetooth: Add support for Mediatek Bluetooth device [0e8d:763f]

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

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

From: "Cho, Yu-Chen" <[email protected]>

commit 178c059e7640aa8e50213400c6f3dde00189d979 upstream.

This patch adds support for Mediatek Bluetooth device

T: Bus=02 Lev=01 Prnt=01 Port=03 Cnt=01 Dev#= 2 Spd=480 MxCh= 0
D: Ver= 2.01 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=0e8d ProdID=763f Rev= 1.00
S: Manufacturer=MediaTek
S: Product=BT
S: SerialNumber=1.0
C:* #Ifs= 2 Cfg#= 1 Atr=a0 MxPwr=450mA
A: FirstIf#= 0 IfCount= 2 Cls=ff(vend.) Sub=ff Prot=ff
I:* If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=125us
E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=125us
E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
I: If#= 1 Alt= 1 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms
I: If#= 1 Alt= 2 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms
I: If#= 1 Alt= 3 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms
I: If#= 1 Alt= 4 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms
I: If#= 1 Alt= 5 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms
I: If#= 1 Alt= 6 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
E: Ad=03(O) Atr=01(Isoc) MxPS= 63 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 63 Ivl=1ms

Signed-off-by: Cho, Yu-Chen <[email protected]>
Signed-off-by: Gustavo Padovan <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/bluetooth/btusb.c | 3 +++
1 file changed, 3 insertions(+)

--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -57,6 +57,9 @@ static struct usb_device_id btusb_table[
/* Apple-specific (Broadcom) devices */
{ USB_VENDOR_AND_INTERFACE_INFO(0x05ac, 0xff, 0x01, 0x01) },

+ /* MediaTek MT76x0E */
+ { USB_DEVICE(0x0e8d, 0x763f) },
+
/* Broadcom SoftSailing reporting vendor specific */
{ USB_DEVICE(0x0a5c, 0x21e1) },


2013-08-09 02:13:53

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 042/102] mac80211: fix monitor interface suspend crash regression

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

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

From: Stanislaw Gruszka <[email protected]>

commit cd34f647a78e7f2296fcb72392b9e5c832793e65 upstream.

My commit:

commit 12e7f517029dad819c45eca9ca01fdb9ba57616b
Author: Stanislaw Gruszka <[email protected]>
Date: Thu Feb 28 10:55:26 2013 +0100

mac80211: cleanup generic suspend/resume procedures

removed check for deleting MONITOR and AP_VLAN when suspend. That can
cause a crash (i.e. in iwlagn_mac_remove_interface()) since we remove
interface in the driver that we did not add before.

Reference:
http://marc.info/?l=linux-kernel&m=137391815113860&w=2

Bisected-by: Ortwin Glück <[email protected]>
Reported-and-tested-by: Ortwin Glück <[email protected]>
Signed-off-by: Stanislaw Gruszka <[email protected]>
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
net/mac80211/pm.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)

--- a/net/mac80211/pm.c
+++ b/net/mac80211/pm.c
@@ -99,10 +99,13 @@ int __ieee80211_suspend(struct ieee80211
}
mutex_unlock(&local->sta_mtx);

- /* remove all interfaces */
+ /* remove all interfaces that were created in the driver */
list_for_each_entry(sdata, &local->interfaces, list) {
- if (!ieee80211_sdata_running(sdata))
+ if (!ieee80211_sdata_running(sdata) ||
+ sdata->vif.type == NL80211_IFTYPE_AP_VLAN ||
+ sdata->vif.type == NL80211_IFTYPE_MONITOR)
continue;
+
drv_remove_interface(local, sdata);
}


2013-08-09 01:58:59

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 039/102] mac80211/minstrel_ht: fix cck rate sampling

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

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

From: Felix Fietkau <[email protected]>

commit 1cd158573951f737fbc878a35cb5eb47bf9af3d5 upstream.

The CCK group needs special treatment to set the right flags and rate
index. Add this missing check to prevent setting broken rates for tx
packets.

Signed-off-by: Felix Fietkau <[email protected]>
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
net/mac80211/rc80211_minstrel_ht.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)

--- a/net/mac80211/rc80211_minstrel_ht.c
+++ b/net/mac80211/rc80211_minstrel_ht.c
@@ -804,10 +804,18 @@ minstrel_ht_get_rate(void *priv, struct

sample_group = &minstrel_mcs_groups[sample_idx / MCS_GROUP_RATES];
info->flags |= IEEE80211_TX_CTL_RATE_CTRL_PROBE;
+ rate->count = 1;
+
+ if (sample_idx / MCS_GROUP_RATES == MINSTREL_CCK_GROUP) {
+ int idx = sample_idx % ARRAY_SIZE(mp->cck_rates);
+ rate->idx = mp->cck_rates[idx];
+ rate->flags = 0;
+ return;
+ }
+
rate->idx = sample_idx % MCS_GROUP_RATES +
(sample_group->streams - 1) * MCS_GROUP_RATES;
rate->flags = IEEE80211_TX_RC_MCS | sample_group->flags;
- rate->count = 1;
}

static void

2013-08-09 02:14:10

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 046/102] Bluetooth: ath3k: Add support for Fujitsu Lifebook UH5x2 [04c5:1330]

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

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

From: Thomas Loo <[email protected]>

commit 84eb2ae1807dd1467bf6f500fc69ae61f1907b75 upstream.

The Fujitsu Lifebook UH552/UH572 ships with a Qualcomm AR9462/AR3012
WLAN/BT-Combo card.
Add device ID to the ath3k driver to enable the bluetooth side of things.
Patch against v3.10.

T: Bus=03 Lev=01 Prnt=01 Port=02 Cnt=01 Dev#= 3 Spd=12 MxCh= 0
D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=04c5 ProdID=1330 Rev=00.02
C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb

Signed-off-by: Thomas Loo <[email protected]>
Signed-off-by: Gustavo Padovan <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/bluetooth/ath3k.c | 2 ++
drivers/bluetooth/btusb.c | 1 +
2 files changed, 3 insertions(+)

--- a/drivers/bluetooth/ath3k.c
+++ b/drivers/bluetooth/ath3k.c
@@ -91,6 +91,7 @@ static struct usb_device_id ath3k_table[
{ USB_DEVICE(0x0489, 0xe04e) },
{ USB_DEVICE(0x0489, 0xe056) },
{ USB_DEVICE(0x0489, 0xe04d) },
+ { USB_DEVICE(0x04c5, 0x1330) },

/* Atheros AR5BBU12 with sflash firmware */
{ USB_DEVICE(0x0489, 0xE02C) },
@@ -128,6 +129,7 @@ static struct usb_device_id ath3k_blist_
{ USB_DEVICE(0x0489, 0xe04e), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0489, 0xe056), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0489, 0xe04d), .driver_info = BTUSB_ATH3012 },
+ { USB_DEVICE(0x04c5, 0x1330), .driver_info = BTUSB_ATH3012 },

/* Atheros AR5BBU22 with sflash firmware */
{ USB_DEVICE(0x0489, 0xE03C), .driver_info = BTUSB_ATH3012 },
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -151,6 +151,7 @@ static struct usb_device_id blacklist_ta
{ USB_DEVICE(0x0489, 0xe04e), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0489, 0xe056), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0489, 0xe04d), .driver_info = BTUSB_ATH3012 },
+ { USB_DEVICE(0x04c5, 0x1330), .driver_info = BTUSB_ATH3012 },

/* Atheros AR5BBU12 with sflash firmware */
{ USB_DEVICE(0x0489, 0xe02c), .driver_info = BTUSB_IGNORE },

2013-08-09 02:14:32

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 045/102] Bluetooth: Fix invalid length check in l2cap_information_rsp()

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

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

From: Jaganath Kanakkassery <[email protected]>

commit da9910ac4a816b4340944c78d94c02a35527db46 upstream.

The length check is invalid since the length varies with type of
info response.

This was introduced by the commit cb3b3152b2f5939d67005cff841a1ca748b19888

Because of this, l2cap info rsp is not handled and command reject is sent.

> ACL data: handle 11 flags 0x02 dlen 16
L2CAP(s): Info rsp: type 2 result 0
Extended feature mask 0x00b8
Enhanced Retransmission mode
Streaming mode
FCS Option
Fixed Channels
< ACL data: handle 11 flags 0x00 dlen 10
L2CAP(s): Command rej: reason 0
Command not understood

Signed-off-by: Jaganath Kanakkassery <[email protected]>
Signed-off-by: Chan-Yeol Park <[email protected]>
Acked-by: Johan Hedberg <[email protected]>
Signed-off-by: Gustavo Padovan <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
net/bluetooth/l2cap_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/net/bluetooth/l2cap_core.c
+++ b/net/bluetooth/l2cap_core.c
@@ -4240,7 +4240,7 @@ static inline int l2cap_disconnect_rsp(s
u16 dcid, scid;
struct l2cap_chan *chan;

- if (cmd_len != sizeof(*rsp))
+ if (cmd_len < sizeof(*rsp))
return -EPROTO;

scid = __le16_to_cpu(rsp->scid);

2013-08-09 01:58:57

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 040/102] mac80211: fix duplicate retransmission detection

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

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

From: Johannes Berg <[email protected]>

commit 6b0f32745dcfba01d7be33acd1b40306c7a914c6 upstream.

The duplicate retransmission detection code in mac80211
erroneously attempts to do the check for every frame,
even frames that don't have a sequence control field or
that don't use it (QoS-Null frames.)

This is problematic because it causes the code to access
data beyond the end of the SKB and depending on the data
there will drop packets erroneously.

Correct the code to not do duplicate detection for such
frames.

I found this error while testing AP powersave, it lead
to retransmitted PS-Poll frames being dropped entirely
as the data beyond the end of the SKB was always zero.

Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
net/mac80211/rx.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)

--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -932,8 +932,14 @@ ieee80211_rx_h_check(struct ieee80211_rx
struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)rx->skb->data;
struct ieee80211_rx_status *status = IEEE80211_SKB_RXCB(rx->skb);

- /* Drop duplicate 802.11 retransmissions (IEEE 802.11 Chap. 9.2.9) */
- if (rx->sta && !is_multicast_ether_addr(hdr->addr1)) {
+ /*
+ * Drop duplicate 802.11 retransmissions
+ * (IEEE 802.11-2012: 9.3.2.10 "Duplicate detection and recovery")
+ */
+ if (rx->skb->len >= 24 && rx->sta &&
+ !ieee80211_is_ctl(hdr->frame_control) &&
+ !ieee80211_is_qos_nullfunc(hdr->frame_control) &&
+ !is_multicast_ether_addr(hdr->addr1)) {
if (unlikely(ieee80211_has_retry(hdr->frame_control) &&
rx->sta->last_seq_ctrl[rx->seqno_idx] ==
hdr->seq_ctrl)) {

2013-08-09 02:14:50

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 044/102] ath: wil6210: Fix build error

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

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

From: Larry Finger <[email protected]>

commit 5d21608a592a9afcac8d82c6478a564e911ce70b upstream.

Building driver wil6210 in 3.10 and 3.11 kernels yields the following errors:

CC [M] drivers/net/wireless/ath/wil6210/debugfs.o
drivers/net/wireless/ath/wil6210/debugfs.c: In function 'wil_print_ring':
drivers/net/wireless/ath/wil6210/debugfs.c:163:11: error: pointer targets in passing argument 5 of 'hex_dump_to_buffer' differ in signedness [-Werror=pointer-sign]
false);
^
In file included from include/linux/kernel.h:13:0,
from include/linux/cache.h:4,
from include/linux/time.h:4,
from include/linux/stat.h:18,
from include/linux/module.h:10,
from drivers/net/wireless/ath/wil6210/debugfs.c:17:
include/linux/printk.h:361:13: note: expected 'char *' but argument is of type 'unsigned char *'
extern void hex_dump_to_buffer(const void *buf, size_t len,
^
drivers/net/wireless/ath/wil6210/debugfs.c: In function 'wil_txdesc_debugfs_show':
drivers/net/wireless/ath/wil6210/debugfs.c:429:10: error: pointer targets in passing argument 5 of 'hex_dump_to_buffer' differ in signedness [-Werror=pointer-sign]
sizeof(printbuf), false);
^
In file included from include/linux/kernel.h:13:0,
from include/linux/cache.h:4,
from include/linux/time.h:4,
from include/linux/stat.h:18,
from include/linux/module.h:10,
from drivers/net/wireless/ath/wil6210/debugfs.c:17:
include/linux/printk.h:361:13: note: expected 'char *' but argument is of type 'unsigned char *'
extern void hex_dump_to_buffer(const void *buf, size_t len,
^
cc1: all warnings being treated as errors
make[5]: *** [drivers/net/wireless/ath/wil6210/debugfs.o] Error 1
make[4]: *** [drivers/net/wireless/ath/wil6210] Error 2
make[3]: *** [drivers/net/wireless/ath] Error 2
make[2]: *** [drivers/net/wireless] Error 2
make[1]: *** [drivers/net] Error 2
make: *** [drivers] Error 2

These errors are fixed by changing the type of the buffer from "unsigned char *" to "char *".

Reported-by: Thomas Fjellstrom <[email protected]>
Tested-by: Thomas Fjellstrom <[email protected]>
Signed-off-by: Larry Finger <[email protected]>
Cc: Thomas Fjellstrom <[email protected]>
Signed-off-by: Vladimir Kondratiev <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/net/wireless/ath/wil6210/debugfs.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/net/wireless/ath/wil6210/debugfs.c
+++ b/drivers/net/wireless/ath/wil6210/debugfs.c
@@ -145,7 +145,7 @@ static void wil_print_ring(struct seq_fi
le16_to_cpu(hdr.type), hdr.flags);
if (len <= MAX_MBOXITEM_SIZE) {
int n = 0;
- unsigned char printbuf[16 * 3 + 2];
+ char printbuf[16 * 3 + 2];
unsigned char databuf[MAX_MBOXITEM_SIZE];
void __iomem *src = wmi_buffer(wil, d.addr) +
sizeof(struct wil6210_mbox_hdr);
@@ -416,7 +416,7 @@ static int wil_txdesc_debugfs_show(struc
seq_printf(s, " SKB = %p\n", skb);

if (skb) {
- unsigned char printbuf[16 * 3 + 2];
+ char printbuf[16 * 3 + 2];
int i = 0;
int len = skb_headlen(skb);
void *p = skb->data;

2013-08-09 02:15:09

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 043/102] ixgbe: Fix Tx Hang issue with lldpad on 82598EB

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

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

From: Jacob Keller <[email protected]>

commit 1eb9ac14c34a948bf1538bfb9034e8ab29099a64 upstream.

This patch fixes an issue with the 82598EB device, where lldpad is causing Tx
Hangs on the card as soon as it attempts to configure DCB for the device. The
adapter will continually Tx hang and reset in a loop.

Signed-off-by: Jacob Keller <[email protected]>
Tested-by: Phil Schmitt <[email protected]>
Tested-by: Jack Morgan <[email protected]>
Signed-off-by: Jeff Kirsher <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/net/ethernet/intel/ixgbe/ixgbe_dcb_82598.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)

--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_dcb_82598.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_dcb_82598.c
@@ -108,9 +108,8 @@ s32 ixgbe_dcb_config_tx_desc_arbiter_825

/* Enable arbiter */
reg &= ~IXGBE_DPMCS_ARBDIS;
- /* Enable DFP and Recycle mode */
- reg |= (IXGBE_DPMCS_TDPAC | IXGBE_DPMCS_TRM);
reg |= IXGBE_DPMCS_TSOEF;
+
/* Configure Max TSO packet size 34KB including payload and headers */
reg |= (0x4 << IXGBE_DPMCS_MTSOS_SHIFT);


2013-08-09 02:15:32

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 034/102] iwlwifi: mvm: fix flushing not started aggregation sessions

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

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

From: Johannes Berg <[email protected]>

commit b6658ff80c43bcf84be0bbe371c88af1452e7776 upstream.

When a not fully started aggregation session is destroyed
and flushed, we get a warning, e.g.

WARNING: at drivers/net/wireless/iwlwifi/pcie/tx.c:1142 iwl_trans_pcie_txq_disable+0x11c/0x160
queue 16 not used
Modules linked in: [...]
Pid: 5135, comm: hostapd Tainted: G W O 3.5.0 #10
Call Trace:
wlan0: driver sets block=0 for sta 00:03:7f:10:44:d3
[<ffffffff81036492>] warn_slowpath_common+0x72/0xa0
[<ffffffff81036577>] warn_slowpath_fmt+0x47/0x50
[<ffffffffa0368d6c>] iwl_trans_pcie_txq_disable+0x11c/0x160 [iwlwifi]
[<ffffffffa03a2099>] iwl_mvm_sta_tx_agg_flush+0xe9/0x150 [iwlmvm]
[<ffffffffa0396c43>] iwl_mvm_mac_ampdu_action+0xf3/0x1e0 [iwlmvm]
[<ffffffffa0293ad3>] ___ieee80211_stop_tx_ba_session+0x193/0x920 [mac80211]
[<ffffffffa0294ed8>] __ieee80211_stop_tx_ba_session+0x48/0x70 [mac80211]
[<ffffffffa029159f>] ieee80211_sta_tear_down_BA_sessions+0x4f/0x80 [mac80211]
[<ffffffffa028a686>] __sta_info_destroy+0x66/0x370 [mac80211]
[<ffffffffa028abb4>] sta_info_destroy_addr_bss+0x44/0x70 [mac80211]
[<ffffffffa02a3e26>] ieee80211_del_station+0x26/0x50 [mac80211]
[<ffffffffa01e6395>] nl80211_del_station+0x85/0x200 [cfg80211]

when a station deauthenticated from us without fully setting
up the aggregation session.

Fix this by checking the aggregation state before removing
the hardware queue.

Reviewed-by: Emmanuel Grumbach <[email protected]>
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/net/wireless/iwlwifi/mvm/sta.c | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)

--- a/drivers/net/wireless/iwlwifi/mvm/sta.c
+++ b/drivers/net/wireless/iwlwifi/mvm/sta.c
@@ -898,6 +898,7 @@ int iwl_mvm_sta_tx_agg_flush(struct iwl_
struct iwl_mvm_sta *mvmsta = (void *)sta->drv_priv;
struct iwl_mvm_tid_data *tid_data = &mvmsta->tid_data[tid];
u16 txq_id;
+ enum iwl_mvm_agg_state old_state;

/*
* First set the agg state to OFF to avoid calling
@@ -907,13 +908,17 @@ int iwl_mvm_sta_tx_agg_flush(struct iwl_
txq_id = tid_data->txq_id;
IWL_DEBUG_TX_QUEUES(mvm, "Flush AGG: sta %d tid %d q %d state %d\n",
mvmsta->sta_id, tid, txq_id, tid_data->state);
+ old_state = tid_data->state;
tid_data->state = IWL_AGG_OFF;
spin_unlock_bh(&mvmsta->lock);

- if (iwl_mvm_flush_tx_path(mvm, BIT(txq_id), true))
- IWL_ERR(mvm, "Couldn't flush the AGG queue\n");
+ if (old_state >= IWL_AGG_ON) {
+ if (iwl_mvm_flush_tx_path(mvm, BIT(txq_id), true))
+ IWL_ERR(mvm, "Couldn't flush the AGG queue\n");
+
+ iwl_trans_txq_disable(mvm->trans, tid_data->txq_id);
+ }

- iwl_trans_txq_disable(mvm->trans, tid_data->txq_id);
mvm->queue_to_mac80211[tid_data->txq_id] =
IWL_INVALID_MAC80211_QUEUE;


2013-08-09 02:15:54

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 041/102] mac80211: fix ethtool stats for non-station interfaces

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

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

From: Johannes Berg <[email protected]>

commit e13bae4f807401729b3f27c7e882a96b8b292809 upstream.

As reported in https://bugzilla.kernel.org/show_bug.cgi?id=60514,
the station loop never initialises 'sinfo' and therefore adds up
a stack values, leaking stack information (the number of times it
adds values is easily obtained another way.)

Fix this by initialising the sinfo for each station to add.

Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
net/mac80211/cfg.c | 2 ++
1 file changed, 2 insertions(+)

--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -652,6 +652,8 @@ static void ieee80211_get_et_stats(struc
if (sta->sdata->dev != dev)
continue;

+ sinfo.filled = 0;
+ sta_set_sinfo(sta, &sinfo);
i = 0;
ADD_STA_STATS(sta);
}

2013-08-09 02:16:13

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 038/102] mac80211/minstrel: fix NULL pointer dereference issue

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

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

From: Felix Fietkau <[email protected]>

commit 5c9fc93bc9bc417418fc1b6366833ae6a07b804d upstream.

When priv_sta == NULL, mi->prev_sample is dereferenced too early. Move
the assignment further down, after the rate_control_send_low call.

Reported-by: Krzysztof Mazur <[email protected]>
Signed-off-by: Felix Fietkau <[email protected]>
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
net/mac80211/rc80211_minstrel.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

--- a/net/mac80211/rc80211_minstrel.c
+++ b/net/mac80211/rc80211_minstrel.c
@@ -290,7 +290,7 @@ minstrel_get_rate(void *priv, struct iee
struct minstrel_rate *msr, *mr;
unsigned int ndx;
bool mrr_capable;
- bool prev_sample = mi->prev_sample;
+ bool prev_sample;
int delta;
int sampling_ratio;

@@ -314,6 +314,7 @@ minstrel_get_rate(void *priv, struct iee
(mi->sample_count + mi->sample_deferred / 2);

/* delta < 0: no sampling required */
+ prev_sample = mi->prev_sample;
mi->prev_sample = false;
if (delta < 0 || (!mrr_capable && prev_sample))
return;

2013-08-09 01:58:51

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 031/102] iwlwifi: mvm: fix bug in scan ssid

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

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

From: David Spinadel <[email protected]>

commit fe04e83706037802c502ea41c0d1799ec35fc0d7 upstream.

Increment index in each iteration. Without this increment we are
overriding the added SSIDs and we will send only the last SSId
and (n_ssids - 1) broadcast probes.

Signed-off-by: David Spinadel <[email protected]>
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/net/wireless/iwlwifi/mvm/scan.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/net/wireless/iwlwifi/mvm/scan.c
+++ b/drivers/net/wireless/iwlwifi/mvm/scan.c
@@ -137,8 +137,8 @@ static void iwl_mvm_scan_fill_ssids(stru
{
int fw_idx, req_idx;

- fw_idx = 0;
- for (req_idx = req->n_ssids - 1; req_idx > 0; req_idx--) {
+ for (req_idx = req->n_ssids - 1, fw_idx = 0; req_idx > 0;
+ req_idx--, fw_idx++) {
cmd->direct_scan[fw_idx].id = WLAN_EID_SSID;
cmd->direct_scan[fw_idx].len = req->ssids[req_idx].ssid_len;
memcpy(cmd->direct_scan[fw_idx].ssid,

2013-08-09 02:16:38

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 037/102] nl80211: fix mgmt tx status and testmode reporting for netns

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

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

From: Michal Kazior <[email protected]>

commit a0ec570f4f69c4cb700d743a915096c2c8f56a99 upstream.

These two events were sent to the default network
namespace.

This caused AP mode in a non-default netns to not
work correctly. Mgmt tx status was multicasted to
a different (default) netns instead of the one the
AP was in.

Signed-off-by: Michal Kazior <[email protected]>
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
net/wireless/nl80211.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)

--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -6588,12 +6588,14 @@ EXPORT_SYMBOL(cfg80211_testmode_alloc_ev

void cfg80211_testmode_event(struct sk_buff *skb, gfp_t gfp)
{
+ struct cfg80211_registered_device *rdev = ((void **)skb->cb)[0];
void *hdr = ((void **)skb->cb)[1];
struct nlattr *data = ((void **)skb->cb)[2];

nla_nest_end(skb, data);
genlmsg_end(skb, hdr);
- genlmsg_multicast(skb, 0, nl80211_testmode_mcgrp.id, gfp);
+ genlmsg_multicast_netns(wiphy_net(&rdev->wiphy), skb, 0,
+ nl80211_testmode_mcgrp.id, gfp);
}
EXPORT_SYMBOL(cfg80211_testmode_event);
#endif
@@ -10028,7 +10030,8 @@ void cfg80211_mgmt_tx_status(struct wire

genlmsg_end(msg, hdr);

- genlmsg_multicast(msg, 0, nl80211_mlme_mcgrp.id, gfp);
+ genlmsg_multicast_netns(wiphy_net(&rdev->wiphy), msg, 0,
+ nl80211_mlme_mcgrp.id, gfp);
return;

nla_put_failure:

2013-08-09 02:16:56

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 035/102] ath9k_htc: do some initial hardware configuration

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

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

From: Oleksij Rempel <[email protected]>

commit dc2a87f519a4d8cb376ab54f22b6b98a943b51ce upstream.

Currently we configure harwdare and clock, only after
interface start. In this case, if we reload module or
reboot PC without configuring adapter, firmware will freeze.
There is no software way to reset adpter.

This patch add initial configuration and set it in
disabled state, to avoid this freeze. Behaviour of this patch
should be similar to: ifconfig wlan0 up; ifconfig wlan0 down.

Bug: https://github.com/qca/open-ath9k-htc-firmware/issues/1
Tested-by: Bo Shi <[email protected]>
Signed-off-by: Oleksij Rempel <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/net/wireless/ath/ath9k/htc_drv_init.c | 1 +
1 file changed, 1 insertion(+)

--- a/drivers/net/wireless/ath/ath9k/htc_drv_init.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_init.c
@@ -846,6 +846,7 @@ static int ath9k_init_device(struct ath9
if (error != 0)
goto err_rx;

+ ath9k_hw_disable(priv->ah);
#ifdef CONFIG_MAC80211_LEDS
/* must be initialized before ieee80211_register_hw */
priv->led_cdev.default_trigger = ieee80211_create_tpt_led_trigger(priv->hw,

2013-08-09 02:16:55

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 036/102] ath9k_htc: reboot firmware if it was loaded

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

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

From: Oleksij Rempel <[email protected]>

commit 4928bd2ef8ece262f4f314630219999a91eaa440 upstream.

Currently ath9k_htc will reboot firmware only if interface was
ever started. Which lead to the problem in case where interface
was never started but module need to be reloaded.

This patch will partially fix bug "ath9k_htc: Target is unresponsive"
https://github.com/qca/open-ath9k-htc-firmware/issues/1

Reproduction case:
- plug adapter
- make sure nothing will touch it. Stop Networkmanager or blacklist mac address of this adapter.
- rmmod ath9k_htc; sleep 1; modprobe ath9k_htc

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

---
drivers/net/wireless/ath/ath9k/hif_usb.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)

--- a/drivers/net/wireless/ath/ath9k/hif_usb.c
+++ b/drivers/net/wireless/ath/ath9k/hif_usb.c
@@ -1289,7 +1289,9 @@ static void ath9k_hif_usb_disconnect(str

usb_set_intfdata(interface, NULL);

- if (!unplugged && (hif_dev->flags & HIF_USB_START))
+ /* If firmware was loaded we should drop it
+ * go back to first stage bootloader. */
+ if (!unplugged && (hif_dev->flags & HIF_USB_READY))
ath9k_hif_usb_reboot(udev);

kfree(hif_dev);

2013-08-09 02:17:29

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 025/102] dma: pl330: Fix cyclic transfers

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

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

From: Lars-Peter Clausen <[email protected]>

commit fc51446021f42aca8906e701fc2292965aafcb15 upstream.

Allocate a descriptor for each period of a cyclic transfer, not just the first.
Also since the callback needs to be called for each finished period make sure to
initialize the callback and callback_param fields of each descriptor in a cyclic
transfer.

Signed-off-by: Lars-Peter Clausen <[email protected]>
Signed-off-by: Vinod Koul <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/dma/pl330.c | 93 +++++++++++++++++++++++++++++++++++++---------------
1 file changed, 67 insertions(+), 26 deletions(-)

--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -2527,6 +2527,10 @@ static dma_cookie_t pl330_tx_submit(stru
/* Assign cookies to all nodes */
while (!list_empty(&last->node)) {
desc = list_entry(last->node.next, struct dma_pl330_desc, node);
+ if (pch->cyclic) {
+ desc->txd.callback = last->txd.callback;
+ desc->txd.callback_param = last->txd.callback_param;
+ }

dma_cookie_assign(&desc->txd);

@@ -2710,45 +2714,82 @@ static struct dma_async_tx_descriptor *p
size_t period_len, enum dma_transfer_direction direction,
unsigned long flags, void *context)
{
- struct dma_pl330_desc *desc;
+ struct dma_pl330_desc *desc = NULL, *first = NULL;
struct dma_pl330_chan *pch = to_pchan(chan);
+ struct dma_pl330_dmac *pdmac = pch->dmac;
+ unsigned int i;
dma_addr_t dst;
dma_addr_t src;

- desc = pl330_get_desc(pch);
- if (!desc) {
- dev_err(pch->dmac->pif.dev, "%s:%d Unable to fetch desc\n",
- __func__, __LINE__);
+ if (len % period_len != 0)
return NULL;
- }

- switch (direction) {
- case DMA_MEM_TO_DEV:
- desc->rqcfg.src_inc = 1;
- desc->rqcfg.dst_inc = 0;
- desc->req.rqtype = MEMTODEV;
- src = dma_addr;
- dst = pch->fifo_addr;
- break;
- case DMA_DEV_TO_MEM:
- desc->rqcfg.src_inc = 0;
- desc->rqcfg.dst_inc = 1;
- desc->req.rqtype = DEVTOMEM;
- src = pch->fifo_addr;
- dst = dma_addr;
- break;
- default:
+ if (!is_slave_direction(direction)) {
dev_err(pch->dmac->pif.dev, "%s:%d Invalid dma direction\n",
__func__, __LINE__);
return NULL;
}

- desc->rqcfg.brst_size = pch->burst_sz;
- desc->rqcfg.brst_len = 1;
+ for (i = 0; i < len / period_len; i++) {
+ desc = pl330_get_desc(pch);
+ if (!desc) {
+ dev_err(pch->dmac->pif.dev, "%s:%d Unable to fetch desc\n",
+ __func__, __LINE__);

- pch->cyclic = true;
+ if (!first)
+ return NULL;
+
+ spin_lock_irqsave(&pdmac->pool_lock, flags);
+
+ while (!list_empty(&first->node)) {
+ desc = list_entry(first->node.next,
+ struct dma_pl330_desc, node);
+ list_move_tail(&desc->node, &pdmac->desc_pool);
+ }
+
+ list_move_tail(&first->node, &pdmac->desc_pool);
+
+ spin_unlock_irqrestore(&pdmac->pool_lock, flags);
+
+ return NULL;
+ }
+
+ switch (direction) {
+ case DMA_MEM_TO_DEV:
+ desc->rqcfg.src_inc = 1;
+ desc->rqcfg.dst_inc = 0;
+ desc->req.rqtype = MEMTODEV;
+ src = dma_addr;
+ dst = pch->fifo_addr;
+ break;
+ case DMA_DEV_TO_MEM:
+ desc->rqcfg.src_inc = 0;
+ desc->rqcfg.dst_inc = 1;
+ desc->req.rqtype = DEVTOMEM;
+ src = pch->fifo_addr;
+ dst = dma_addr;
+ break;
+ default:
+ break;
+ }

- fill_px(&desc->px, dst, src, period_len);
+ desc->rqcfg.brst_size = pch->burst_sz;
+ desc->rqcfg.brst_len = 1;
+ fill_px(&desc->px, dst, src, period_len);
+
+ if (!first)
+ first = desc;
+ else
+ list_add_tail(&desc->node, &first->node);
+
+ dma_addr += period_len;
+ }
+
+ if (!desc)
+ return NULL;
+
+ pch->cyclic = true;
+ desc->txd.flags = flags;

return &desc->txd;
}

2013-08-09 02:17:44

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 033/102] iwlwifi: add DELL SKU for 5150 HMC

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

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

From: Emmanuel Grumbach <[email protected]>

commit a1923f1d4723e5757cefdd60f7c7ab30e472007a upstream.

This SKU was missing in the list of supported devices

https://bugzilla.kernel.org/show_bug.cgi?id=60577

Signed-off-by: Emmanuel Grumbach <[email protected]>
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/net/wireless/iwlwifi/pcie/drv.c | 1 +
1 file changed, 1 insertion(+)

--- a/drivers/net/wireless/iwlwifi/pcie/drv.c
+++ b/drivers/net/wireless/iwlwifi/pcie/drv.c
@@ -129,6 +129,7 @@ static DEFINE_PCI_DEVICE_TABLE(iwl_hw_ca
{IWL_PCI_DEVICE(0x423C, 0x1306, iwl5150_abg_cfg)}, /* Half Mini Card */
{IWL_PCI_DEVICE(0x423C, 0x1221, iwl5150_agn_cfg)}, /* Mini Card */
{IWL_PCI_DEVICE(0x423C, 0x1321, iwl5150_agn_cfg)}, /* Half Mini Card */
+ {IWL_PCI_DEVICE(0x423C, 0x1326, iwl5150_abg_cfg)}, /* Half Mini Card */

{IWL_PCI_DEVICE(0x423D, 0x1211, iwl5150_agn_cfg)}, /* Mini Card */
{IWL_PCI_DEVICE(0x423D, 0x1311, iwl5150_agn_cfg)}, /* Half Mini Card */

2013-08-09 02:18:00

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 032/102] iwlwifi: mvm: refuse connection to APs with BI < 16

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

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

From: Johannes Berg <[email protected]>

commit 48bc13072109ea58465542aa1ee31b4e1065468a upstream.

Due to a firmware bug, it crashes when the beacon interval
is smaller than 16. Avoid this by refusing the station state
change creating the AP station, causing mac80211 to abandon
the attempt to connect to the AP, and eventually wpa_s to
blacklist it.

Reviewed-by: Emmanuel Grumbach <[email protected]>
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/net/wireless/iwlwifi/mvm/mac80211.c | 16 ++++++++++++++++
1 file changed, 16 insertions(+)

--- a/drivers/net/wireless/iwlwifi/mvm/mac80211.c
+++ b/drivers/net/wireless/iwlwifi/mvm/mac80211.c
@@ -987,6 +987,21 @@ static int iwl_mvm_mac_sta_state(struct
mutex_lock(&mvm->mutex);
if (old_state == IEEE80211_STA_NOTEXIST &&
new_state == IEEE80211_STA_NONE) {
+ /*
+ * Firmware bug - it'll crash if the beacon interval is less
+ * than 16. We can't avoid connecting at all, so refuse the
+ * station state change, this will cause mac80211 to abandon
+ * attempts to connect to this AP, and eventually wpa_s will
+ * blacklist the AP...
+ */
+ if (vif->type == NL80211_IFTYPE_STATION &&
+ vif->bss_conf.beacon_int < 16) {
+ IWL_ERR(mvm,
+ "AP %pM beacon interval is %d, refusing due to firmware bug!\n",
+ sta->addr, vif->bss_conf.beacon_int);
+ ret = -EINVAL;
+ goto out_unlock;
+ }
ret = iwl_mvm_add_sta(mvm, vif, sta);
} else if (old_state == IEEE80211_STA_NONE &&
new_state == IEEE80211_STA_AUTH) {
@@ -1015,6 +1030,7 @@ static int iwl_mvm_mac_sta_state(struct
} else {
ret = -EIO;
}
+ out_unlock:
mutex_unlock(&mvm->mutex);

return ret;

2013-08-09 02:18:21

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 029/102] USB: mos7840: fix pointer casts

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

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

From: Johan Hovold <[email protected]>

commit 683a0e4d7971c3186dc4d429027debfe309129aa upstream.

Silence compiler warnings on 64-bit systems introduced by commit
05cf0dec ("USB: mos7840: fix race in led handling") which uses the
usb-serial data pointer to temporarily store the device type during
probe but failed to add the required casts.

[gregkh - change uintptr_t to unsigned long]

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

---
drivers/usb/serial/mos7840.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)

--- a/drivers/usb/serial/mos7840.c
+++ b/drivers/usb/serial/mos7840.c
@@ -2236,14 +2236,14 @@ static int mos7840_probe(struct usb_seri

kfree(buf);
out:
- usb_set_serial_data(serial, (void *)device_type);
+ usb_set_serial_data(serial, (void *)(unsigned long)device_type);

return 0;
}

static int mos7840_calc_num_ports(struct usb_serial *serial)
{
- int device_type = (int)usb_get_serial_data(serial);
+ int device_type = (unsigned long)usb_get_serial_data(serial);
int mos7840_num_ports;

mos7840_num_ports = (device_type >> 4) & 0x000F;
@@ -2254,7 +2254,7 @@ static int mos7840_calc_num_ports(struct
static int mos7840_port_probe(struct usb_serial_port *port)
{
struct usb_serial *serial = port->serial;
- int device_type = (int)usb_get_serial_data(serial);
+ int device_type = (unsigned long)usb_get_serial_data(serial);
struct moschip_port *mos7840_port;
int status;
int pnum;

2013-08-09 02:18:40

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 028/102] USB: mos7840: fix race in led handling

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

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

From: Johan Hovold <[email protected]>

commit 05cf0dec5ccc696a7636c84b265b477173498156 upstream.

Fix race in LED handling introduced by commit 0eafe4de ("USB: serial:
mos7840: add support for MCS7810 devices") which reused the port control
urb for manipulating the LED without making sure that the urb is not
already in use. This could lead to the control urb being manipulated
while in flight.

Fix by adding a dedicated LED urb and ctrlrequest along with a LED-busy
flag to handle concurrency.

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

---
drivers/usb/serial/mos7840.c | 59 ++++++++++++++++++++++++++-----------------
1 file changed, 37 insertions(+), 22 deletions(-)

--- a/drivers/usb/serial/mos7840.c
+++ b/drivers/usb/serial/mos7840.c
@@ -185,6 +185,7 @@

enum mos7840_flag {
MOS7840_FLAG_CTRL_BUSY,
+ MOS7840_FLAG_LED_BUSY,
};

static const struct usb_device_id id_table[] = {
@@ -240,9 +241,10 @@ struct moschip_port {

/* For device(s) with LED indicator */
bool has_led;
- bool led_flag;
struct timer_list led_timer1; /* Timer for LED on */
struct timer_list led_timer2; /* Timer for LED off */
+ struct urb *led_urb;
+ struct usb_ctrlrequest *led_dr;

unsigned long flags;
};
@@ -542,7 +544,7 @@ static void mos7840_set_led_async(struct
__u16 reg)
{
struct usb_device *dev = mcs->port->serial->dev;
- struct usb_ctrlrequest *dr = mcs->dr;
+ struct usb_ctrlrequest *dr = mcs->led_dr;

dr->bRequestType = MCS_WR_RTYPE;
dr->bRequest = MCS_WRREQ;
@@ -550,10 +552,10 @@ static void mos7840_set_led_async(struct
dr->wIndex = cpu_to_le16(reg);
dr->wLength = cpu_to_le16(0);

- usb_fill_control_urb(mcs->control_urb, dev, usb_sndctrlpipe(dev, 0),
+ usb_fill_control_urb(mcs->led_urb, dev, usb_sndctrlpipe(dev, 0),
(unsigned char *)dr, NULL, 0, mos7840_set_led_callback, NULL);

- usb_submit_urb(mcs->control_urb, GFP_ATOMIC);
+ usb_submit_urb(mcs->led_urb, GFP_ATOMIC);
}

static void mos7840_set_led_sync(struct usb_serial_port *port, __u16 reg,
@@ -579,7 +581,19 @@ static void mos7840_led_flag_off(unsigne
{
struct moschip_port *mcs = (struct moschip_port *) arg;

- mcs->led_flag = false;
+ clear_bit_unlock(MOS7840_FLAG_LED_BUSY, &mcs->flags);
+}
+
+static void mos7840_led_activity(struct usb_serial_port *port)
+{
+ struct moschip_port *mos7840_port = usb_get_serial_port_data(port);
+
+ if (test_and_set_bit_lock(MOS7840_FLAG_LED_BUSY, &mos7840_port->flags))
+ return;
+
+ mos7840_set_led_async(mos7840_port, 0x0301, MODEM_CONTROL_REGISTER);
+ mod_timer(&mos7840_port->led_timer1,
+ jiffies + msecs_to_jiffies(LED_ON_MS));
}

/*****************************************************************************
@@ -779,14 +793,8 @@ static void mos7840_bulk_in_callback(str
return;
}

- /* Turn on LED */
- if (mos7840_port->has_led && !mos7840_port->led_flag) {
- mos7840_port->led_flag = true;
- mos7840_set_led_async(mos7840_port, 0x0301,
- MODEM_CONTROL_REGISTER);
- mod_timer(&mos7840_port->led_timer1,
- jiffies + msecs_to_jiffies(LED_ON_MS));
- }
+ if (mos7840_port->has_led)
+ mos7840_led_activity(port);

mos7840_port->read_urb_busy = true;
retval = usb_submit_urb(mos7840_port->read_urb, GFP_ATOMIC);
@@ -1467,13 +1475,8 @@ static int mos7840_write(struct tty_stru
data1 = urb->transfer_buffer;
dev_dbg(&port->dev, "bulkout endpoint is %d\n", port->bulk_out_endpointAddress);

- /* Turn on LED */
- if (mos7840_port->has_led && !mos7840_port->led_flag) {
- mos7840_port->led_flag = true;
- mos7840_set_led_sync(port, MODEM_CONTROL_REGISTER, 0x0301);
- mod_timer(&mos7840_port->led_timer1,
- jiffies + msecs_to_jiffies(LED_ON_MS));
- }
+ if (mos7840_port->has_led)
+ mos7840_led_activity(port);

/* send it down the pipe */
status = usb_submit_urb(urb, GFP_ATOMIC);
@@ -2429,6 +2432,14 @@ static int mos7840_port_probe(struct usb
if (device_type == MOSCHIP_DEVICE_ID_7810) {
mos7840_port->has_led = true;

+ mos7840_port->led_urb = usb_alloc_urb(0, GFP_KERNEL);
+ mos7840_port->led_dr = kmalloc(sizeof(*mos7840_port->led_dr),
+ GFP_KERNEL);
+ if (!mos7840_port->led_urb || !mos7840_port->led_dr) {
+ status = -ENOMEM;
+ goto error;
+ }
+
init_timer(&mos7840_port->led_timer1);
mos7840_port->led_timer1.function = mos7840_led_off;
mos7840_port->led_timer1.expires =
@@ -2441,8 +2452,6 @@ static int mos7840_port_probe(struct usb
jiffies + msecs_to_jiffies(LED_OFF_MS);
mos7840_port->led_timer2.data = (unsigned long)mos7840_port;

- mos7840_port->led_flag = false;
-
/* Turn off LED */
mos7840_set_led_sync(port, MODEM_CONTROL_REGISTER, 0x0300);
}
@@ -2464,6 +2473,8 @@ out:
}
return 0;
error:
+ kfree(mos7840_port->led_dr);
+ usb_free_urb(mos7840_port->led_urb);
kfree(mos7840_port->dr);
kfree(mos7840_port->ctrl_buf);
usb_free_urb(mos7840_port->control_urb);
@@ -2484,6 +2495,10 @@ static int mos7840_port_remove(struct us

del_timer_sync(&mos7840_port->led_timer1);
del_timer_sync(&mos7840_port->led_timer2);
+
+ usb_kill_urb(mos7840_port->led_urb);
+ usb_free_urb(mos7840_port->led_urb);
+ kfree(mos7840_port->led_dr);
}
usb_kill_urb(mos7840_port->control_urb);
usb_free_urb(mos7840_port->control_urb);

2013-08-09 01:58:42

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 022/102] serial/mxs-auart: fix race condition in interrupt handler

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

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

From: Uwe Kleine-König <[email protected]>

commit d970d7fe65adff5efe75b4a73c4ffc9be57089f7 upstream.

The handler needs to ack the pending events before actually handling them.
Otherwise a new event might come in after it it considered non-pending or
handled and is acked then without being handled. So this event is only
noticed when the next interrupt happens.

Without this patch an i.MX28 based machine running an rt-patched kernel
regularly hangs during boot.

Signed-off-by: Uwe Kleine-König <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/tty/serial/mxs-auart.c | 17 +++++++++--------
1 file changed, 9 insertions(+), 8 deletions(-)

--- a/drivers/tty/serial/mxs-auart.c
+++ b/drivers/tty/serial/mxs-auart.c
@@ -678,11 +678,18 @@ static void mxs_auart_settermios(struct

static irqreturn_t mxs_auart_irq_handle(int irq, void *context)
{
- u32 istatus, istat;
+ u32 istat;
struct mxs_auart_port *s = context;
u32 stat = readl(s->port.membase + AUART_STAT);

- istatus = istat = readl(s->port.membase + AUART_INTR);
+ istat = readl(s->port.membase + AUART_INTR);
+
+ /* ack irq */
+ writel(istat & (AUART_INTR_RTIS
+ | AUART_INTR_TXIS
+ | AUART_INTR_RXIS
+ | AUART_INTR_CTSMIS),
+ s->port.membase + AUART_INTR_CLR);

if (istat & AUART_INTR_CTSMIS) {
uart_handle_cts_change(&s->port, stat & AUART_STAT_CTS);
@@ -702,12 +709,6 @@ static irqreturn_t mxs_auart_irq_handle(
istat &= ~AUART_INTR_TXIS;
}

- writel(istatus & (AUART_INTR_RTIS
- | AUART_INTR_TXIS
- | AUART_INTR_RXIS
- | AUART_INTR_CTSMIS),
- s->port.membase + AUART_INTR_CLR);
-
return IRQ_HANDLED;
}


2013-08-09 02:18:59

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 017/102] parisc: Fix cache routines to ignore vmas with an invalid pfn

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

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

From: John David Anglin <[email protected]>

commit 50861f5a02dbf939c27d35a26c472885e2844188 upstream.

The parisc architecture does not have a pte special bit. As a result,
special mappings are handled with the VM_PFNMAP and VM_MIXEDMAP flags.
VM_MIXEDMAP mappings may or may not have a "struct page" backing. When
pfn_valid() is false, there is no "struct page" backing. Otherwise, they
are treated as normal pages.

The FireGL driver uses the VM_MIXEDMAP without a backing "struct page".
This treatment caused a panic due to a TLB data miss in
update_mmu_cache. This appeared to be in the code generated for
page_address(). We were in fact using a very circular bit of code to
determine the physical address of the PFN in various cache routines.
This wasn't valid when there was no "struct page" backing. The needed
address can in fact be determined simply from the PFN itself without
using the "struct page".

The attached patch updates update_mmu_cache(), flush_cache_mm(),
flush_cache_range() and flush_cache_page() to check pfn_valid() and to
directly compute the PFN physical and virtual addresses.

Signed-off-by: John David Anglin <[email protected]>
Signed-off-by: Helge Deller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/parisc/kernel/cache.c | 133 +++++++++++++++++++++++----------------------
1 file changed, 70 insertions(+), 63 deletions(-)

--- a/arch/parisc/kernel/cache.c
+++ b/arch/parisc/kernel/cache.c
@@ -71,18 +71,27 @@ flush_cache_all_local(void)
}
EXPORT_SYMBOL(flush_cache_all_local);

+/* Virtual address of pfn. */
+#define pfn_va(pfn) __va(PFN_PHYS(pfn))
+
void
update_mmu_cache(struct vm_area_struct *vma, unsigned long address, pte_t *ptep)
{
- struct page *page = pte_page(*ptep);
+ unsigned long pfn = pte_pfn(*ptep);
+ struct page *page;

- if (pfn_valid(page_to_pfn(page)) && page_mapping(page) &&
- test_bit(PG_dcache_dirty, &page->flags)) {
+ /* We don't have pte special. As a result, we can be called with
+ an invalid pfn and we don't need to flush the kernel dcache page.
+ This occurs with FireGL card in C8000. */
+ if (!pfn_valid(pfn))
+ return;

- flush_kernel_dcache_page(page);
+ page = pfn_to_page(pfn);
+ if (page_mapping(page) && test_bit(PG_dcache_dirty, &page->flags)) {
+ flush_kernel_dcache_page_addr(pfn_va(pfn));
clear_bit(PG_dcache_dirty, &page->flags);
} else if (parisc_requires_coherency())
- flush_kernel_dcache_page(page);
+ flush_kernel_dcache_page_addr(pfn_va(pfn));
}

void
@@ -495,44 +504,42 @@ static inline pte_t *get_ptep(pgd_t *pgd

void flush_cache_mm(struct mm_struct *mm)
{
+ struct vm_area_struct *vma;
+ pgd_t *pgd;
+
/* Flushing the whole cache on each cpu takes forever on
rp3440, etc. So, avoid it if the mm isn't too big. */
- if (mm_total_size(mm) < parisc_cache_flush_threshold) {
- struct vm_area_struct *vma;
-
- if (mm->context == mfsp(3)) {
- for (vma = mm->mmap; vma; vma = vma->vm_next) {
- flush_user_dcache_range_asm(vma->vm_start,
- vma->vm_end);
- if (vma->vm_flags & VM_EXEC)
- flush_user_icache_range_asm(
- vma->vm_start, vma->vm_end);
- }
- } else {
- pgd_t *pgd = mm->pgd;
-
- for (vma = mm->mmap; vma; vma = vma->vm_next) {
- unsigned long addr;
+ if (mm_total_size(mm) >= parisc_cache_flush_threshold) {
+ flush_cache_all();
+ return;
+ }

- for (addr = vma->vm_start; addr < vma->vm_end;
- addr += PAGE_SIZE) {
- pte_t *ptep = get_ptep(pgd, addr);
- if (ptep != NULL) {
- pte_t pte = *ptep;
- __flush_cache_page(vma, addr,
- page_to_phys(pte_page(pte)));
- }
- }
- }
+ if (mm->context == mfsp(3)) {
+ for (vma = mm->mmap; vma; vma = vma->vm_next) {
+ flush_user_dcache_range_asm(vma->vm_start, vma->vm_end);
+ if ((vma->vm_flags & VM_EXEC) == 0)
+ continue;
+ flush_user_icache_range_asm(vma->vm_start, vma->vm_end);
}
return;
}

-#ifdef CONFIG_SMP
- flush_cache_all();
-#else
- flush_cache_all_local();
-#endif
+ pgd = mm->pgd;
+ for (vma = mm->mmap; vma; vma = vma->vm_next) {
+ unsigned long addr;
+
+ for (addr = vma->vm_start; addr < vma->vm_end;
+ addr += PAGE_SIZE) {
+ unsigned long pfn;
+ pte_t *ptep = get_ptep(pgd, addr);
+ if (!ptep)
+ continue;
+ pfn = pte_pfn(*ptep);
+ if (!pfn_valid(pfn))
+ continue;
+ __flush_cache_page(vma, addr, PFN_PHYS(pfn));
+ }
+ }
}

void
@@ -556,33 +563,32 @@ flush_user_icache_range(unsigned long st
void flush_cache_range(struct vm_area_struct *vma,
unsigned long start, unsigned long end)
{
- BUG_ON(!vma->vm_mm->context);
+ unsigned long addr;
+ pgd_t *pgd;

- if ((end - start) < parisc_cache_flush_threshold) {
- if (vma->vm_mm->context == mfsp(3)) {
- flush_user_dcache_range_asm(start, end);
- if (vma->vm_flags & VM_EXEC)
- flush_user_icache_range_asm(start, end);
- } else {
- unsigned long addr;
- pgd_t *pgd = vma->vm_mm->pgd;
+ BUG_ON(!vma->vm_mm->context);

- for (addr = start & PAGE_MASK; addr < end;
- addr += PAGE_SIZE) {
- pte_t *ptep = get_ptep(pgd, addr);
- if (ptep != NULL) {
- pte_t pte = *ptep;
- flush_cache_page(vma,
- addr, pte_pfn(pte));
- }
- }
- }
- } else {
-#ifdef CONFIG_SMP
+ if ((end - start) >= parisc_cache_flush_threshold) {
flush_cache_all();
-#else
- flush_cache_all_local();
-#endif
+ return;
+ }
+
+ if (vma->vm_mm->context == mfsp(3)) {
+ flush_user_dcache_range_asm(start, end);
+ if (vma->vm_flags & VM_EXEC)
+ flush_user_icache_range_asm(start, end);
+ return;
+ }
+
+ pgd = vma->vm_mm->pgd;
+ for (addr = start & PAGE_MASK; addr < end; addr += PAGE_SIZE) {
+ unsigned long pfn;
+ pte_t *ptep = get_ptep(pgd, addr);
+ if (!ptep)
+ continue;
+ pfn = pte_pfn(*ptep);
+ if (pfn_valid(pfn))
+ __flush_cache_page(vma, addr, PFN_PHYS(pfn));
}
}

@@ -591,9 +597,10 @@ flush_cache_page(struct vm_area_struct *
{
BUG_ON(!vma->vm_mm->context);

- flush_tlb_page(vma, vmaddr);
- __flush_cache_page(vma, vmaddr, page_to_phys(pfn_to_page(pfn)));
-
+ if (pfn_valid(pfn)) {
+ flush_tlb_page(vma, vmaddr);
+ __flush_cache_page(vma, vmaddr, PFN_PHYS(pfn));
+ }
}

#ifdef CONFIG_PARISC_TMPALIAS

2013-08-09 02:18:57

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 027/102] USB: mos7840: fix device-type detection

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

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

From: Johan Hovold <[email protected]>

commit 40c24f2893ba0ba7df485871f6aac0c197ceef5b upstream.

Fix race in device-type detection introduced by commit 0eafe4de ("USB:
serial: mos7840: add support for MCS7810 devices") which used a static
variable to hold the device type.

Move type detection to probe and use serial data to store the device
type.

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

---
drivers/usb/serial/mos7840.c | 75 ++++++++++++++++++++-----------------------
1 file changed, 35 insertions(+), 40 deletions(-)

--- a/drivers/usb/serial/mos7840.c
+++ b/drivers/usb/serial/mos7840.c
@@ -187,8 +187,6 @@ enum mos7840_flag {
MOS7840_FLAG_CTRL_BUSY,
};

-static int device_type;
-
static const struct usb_device_id id_table[] = {
{USB_DEVICE(USB_VENDOR_ID_MOSCHIP, MOSCHIP_DEVICE_ID_7840)},
{USB_DEVICE(USB_VENDOR_ID_MOSCHIP, MOSCHIP_DEVICE_ID_7820)},
@@ -839,18 +837,6 @@ static void mos7840_bulk_out_data_callba
/************************************************************************/
/* D R I V E R T T Y I N T E R F A C E F U N C T I O N S */
/************************************************************************/
-#ifdef MCSSerialProbe
-static int mos7840_serial_probe(struct usb_serial *serial,
- const struct usb_device_id *id)
-{
-
- /*need to implement the mode_reg reading and updating\
- structures usb_serial_ device_type\
- (i.e num_ports, num_bulkin,bulkout etc) */
- /* Also we can update the changes attach */
- return 1;
-}
-#endif

/*****************************************************************************
* mos7840_open
@@ -2216,38 +2202,48 @@ static int mos7810_check(struct usb_seri
return 0;
}

-static int mos7840_calc_num_ports(struct usb_serial *serial)
+static int mos7840_probe(struct usb_serial *serial,
+ const struct usb_device_id *id)
{
- __u16 data = 0x00;
+ u16 product = serial->dev->descriptor.idProduct;
u8 *buf;
- int mos7840_num_ports;
+ int device_type;
+
+ if (product == MOSCHIP_DEVICE_ID_7810 ||
+ product == MOSCHIP_DEVICE_ID_7820) {
+ device_type = product;
+ goto out;
+ }

buf = kzalloc(VENDOR_READ_LENGTH, GFP_KERNEL);
- if (buf) {
- usb_control_msg(serial->dev, usb_rcvctrlpipe(serial->dev, 0),
+ if (!buf)
+ return -ENOMEM;
+
+ usb_control_msg(serial->dev, usb_rcvctrlpipe(serial->dev, 0),
MCS_RDREQ, MCS_RD_RTYPE, 0, GPIO_REGISTER, buf,
VENDOR_READ_LENGTH, MOS_WDR_TIMEOUT);
- data = *buf;
- kfree(buf);
- }

- if (serial->dev->descriptor.idProduct == MOSCHIP_DEVICE_ID_7810 ||
- serial->dev->descriptor.idProduct == MOSCHIP_DEVICE_ID_7820) {
- device_type = serial->dev->descriptor.idProduct;
- } else {
- /* For a MCS7840 device GPIO0 must be set to 1 */
- if ((data & 0x01) == 1)
- device_type = MOSCHIP_DEVICE_ID_7840;
- else if (mos7810_check(serial))
- device_type = MOSCHIP_DEVICE_ID_7810;
- else
- device_type = MOSCHIP_DEVICE_ID_7820;
- }
+ /* For a MCS7840 device GPIO0 must be set to 1 */
+ if (buf[0] & 0x01)
+ device_type = MOSCHIP_DEVICE_ID_7840;
+ else if (mos7810_check(serial))
+ device_type = MOSCHIP_DEVICE_ID_7810;
+ else
+ device_type = MOSCHIP_DEVICE_ID_7820;
+
+ kfree(buf);
+out:
+ usb_set_serial_data(serial, (void *)device_type);
+
+ return 0;
+}
+
+static int mos7840_calc_num_ports(struct usb_serial *serial)
+{
+ int device_type = (int)usb_get_serial_data(serial);
+ int mos7840_num_ports;

mos7840_num_ports = (device_type >> 4) & 0x000F;
- serial->num_bulk_in = mos7840_num_ports;
- serial->num_bulk_out = mos7840_num_ports;
- serial->num_ports = mos7840_num_ports;

return mos7840_num_ports;
}
@@ -2255,6 +2251,7 @@ static int mos7840_calc_num_ports(struct
static int mos7840_port_probe(struct usb_serial_port *port)
{
struct usb_serial *serial = port->serial;
+ int device_type = (int)usb_get_serial_data(serial);
struct moschip_port *mos7840_port;
int status;
int pnum;
@@ -2513,9 +2510,7 @@ static struct usb_serial_driver moschip7
.throttle = mos7840_throttle,
.unthrottle = mos7840_unthrottle,
.calc_num_ports = mos7840_calc_num_ports,
-#ifdef MCSSerialProbe
- .probe = mos7840_serial_probe,
-#endif
+ .probe = mos7840_probe,
.ioctl = mos7840_ioctl,
.set_termios = mos7840_set_termios,
.break_ctl = mos7840_break,

2013-08-09 02:19:36

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 024/102] serial/mxs-auart: increase time to wait for transmitter to become idle

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

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

From: Uwe Kleine-König <[email protected]>

commit 079a036f4283e2b0e5c26080b8c5112bc0cc1831 upstream.

Without this patch the driver waits ~1 ms for the UART to become idle. At
115200n8 this time is (theoretically) enough to transfer 11.5 characters
(= 115200 bits/s / (10 Bits/char) * 1ms). As the mxs-auart has a fifo size
of 16 characters the clock is gated too early. The problem is worse for
lower baud rates.

This only happens to really shut down the transmitter in the middle of a
transfer if /dev/ttyAPPx isn't opened in userspace (e.g. by a getty) but
was at least once (because the bootloader doesn't disable the transmitter).

So increase the timeout to 20 ms which should be enough for 9600n8, too.
Moreover skip gating the clock if the timeout is elapsed.

Signed-off-by: Uwe Kleine-König <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/tty/serial/mxs-auart.c | 21 +++++++++++++--------
1 file changed, 13 insertions(+), 8 deletions(-)

--- a/drivers/tty/serial/mxs-auart.c
+++ b/drivers/tty/serial/mxs-auart.c
@@ -851,7 +851,7 @@ auart_console_write(struct console *co,
struct mxs_auart_port *s;
struct uart_port *port;
unsigned int old_ctrl0, old_ctrl2;
- unsigned int to = 1000;
+ unsigned int to = 20000;

if (co->index >= MXS_AUART_PORTS || co->index < 0)
return;
@@ -872,18 +872,23 @@ auart_console_write(struct console *co,

uart_console_write(port, str, count, mxs_auart_console_putchar);

- /*
- * Finally, wait for transmitter to become empty
- * and restore the TCR
- */
+ /* Finally, wait for transmitter to become empty ... */
while (readl(port->membase + AUART_STAT) & AUART_STAT_BUSY) {
+ udelay(1);
if (!to--)
break;
- udelay(1);
}

- writel(old_ctrl0, port->membase + AUART_CTRL0);
- writel(old_ctrl2, port->membase + AUART_CTRL2);
+ /*
+ * ... and restore the TCR if we waited long enough for the transmitter
+ * to be idle. This might keep the transmitter enabled although it is
+ * unused, but that is better than to disable it while it is still
+ * transmitting.
+ */
+ if (!(readl(port->membase + AUART_STAT) & AUART_STAT_BUSY)) {
+ writel(old_ctrl0, port->membase + AUART_CTRL0);
+ writel(old_ctrl2, port->membase + AUART_CTRL2);
+ }

clk_disable(s->clk);
}

2013-08-09 02:19:54

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 021/102] ALSA: compress: fix the return value for SNDRV_COMPRESS_VERSION

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

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

From: Vinod Koul <[email protected]>

commit a8d30608eaed6cc759b8e2e8a8bbbb42591f797f upstream.

the return value of SNDRV_COMPRESS_VERSION always return default -ENOTTY as the
return value was never updated for this call
assign return value from put_user()

Reported-by: Haynes <[email protected]>
Signed-off-by: Vinod Koul <[email protected]>
Signed-off-by: Takashi Iwai <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
sound/core/compress_offload.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/sound/core/compress_offload.c
+++ b/sound/core/compress_offload.c
@@ -743,7 +743,7 @@ static long snd_compr_ioctl(struct file
mutex_lock(&stream->device->lock);
switch (_IOC_NR(cmd)) {
case _IOC_NR(SNDRV_COMPRESS_IOCTL_VERSION):
- put_user(SNDRV_COMPRESS_VERSION,
+ retval = put_user(SNDRV_COMPRESS_VERSION,
(int __user *)arg) ? -EFAULT : 0;
break;
case _IOC_NR(SNDRV_COMPRESS_GET_CAPS):

2013-08-09 02:19:53

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 023/102] serial: arc_uart: Fix module alias

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

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

From: Axel Lin <[email protected]>

commit d5a12ea7a9e58d9e5c19d25cb668aadb396423ec upstream.

Platform drivers use "platform:" prefix in module alias.
Also use DRIVER_NAME in MODULE_ALIAS to make module autoloading work.

Signed-off-by: Axel Lin <[email protected]>
Acked-by: Vineet Gupta <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/tty/serial/arc_uart.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/tty/serial/arc_uart.c
+++ b/drivers/tty/serial/arc_uart.c
@@ -773,6 +773,6 @@ module_init(arc_serial_init);
module_exit(arc_serial_exit);

MODULE_LICENSE("GPL");
-MODULE_ALIAS("plat-arcfpga/uart");
+MODULE_ALIAS("platform:" DRIVER_NAME);
MODULE_AUTHOR("Vineet Gupta");
MODULE_DESCRIPTION("ARC(Synopsys) On-Chip(fpga) serial driver");

2013-08-09 02:20:37

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 020/102] ALSA: hda - Fix missing fixup for Mac Mini with STAC9221

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

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

From: Takashi Iwai <[email protected]>

commit 697aebab78a88c6b164cfb74d19b86817d2ccd82 upstream.

A fixup for Apple Mac Mini was lost during the adaption to the generic
parser because the fallback for the generic ID 8384:7680 was dropped,
and it resulted in the silence output (and maybe other problems).

Unfortunately, just adding the missing subsystem ID wasn't enough, in
this case. The subsystem ID of this machine is 0000:0100 (what Apple
thought...?), and since snd_hda_pick_fixup() doesn't take the vendor
id zero into account, the driver ignored this entry. Now it's fixed
to regard the vendor id zero as a valid value.

Reported-and-tested-by: Linus Torvalds <[email protected]>
Signed-off-by: Takashi Iwai <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
sound/pci/hda/hda_auto_parser.c | 2 +-
sound/pci/hda/patch_sigmatel.c | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)

--- a/sound/pci/hda/hda_auto_parser.c
+++ b/sound/pci/hda/hda_auto_parser.c
@@ -860,7 +860,7 @@ void snd_hda_pick_fixup(struct hda_codec
}
}
if (id < 0 && quirk) {
- for (q = quirk; q->subvendor; q++) {
+ for (q = quirk; q->subvendor || q->subdevice; q++) {
unsigned int vendorid =
q->subdevice | (q->subvendor << 16);
unsigned int mask = 0xffff0000 | q->subdevice_mask;
--- a/sound/pci/hda/patch_sigmatel.c
+++ b/sound/pci/hda/patch_sigmatel.c
@@ -2815,6 +2815,7 @@ static const struct hda_pintbl ecs202_pi

/* codec SSIDs for Intel Mac sharing the same PCI SSID 8384:7680 */
static const struct snd_pci_quirk stac922x_intel_mac_fixup_tbl[] = {
+ SND_PCI_QUIRK(0x0000, 0x0100, "Mac Mini", STAC_INTEL_MAC_V3),
SND_PCI_QUIRK(0x106b, 0x0800, "Mac", STAC_INTEL_MAC_V1),
SND_PCI_QUIRK(0x106b, 0x0600, "Mac", STAC_INTEL_MAC_V2),
SND_PCI_QUIRK(0x106b, 0x0700, "Mac", STAC_INTEL_MAC_V2),

2013-08-09 02:20:57

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 019/102] hwmon: (max6697) fix MAX6581 ideality

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

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

From: Vivien Didelot <[email protected]>

commit 5c52add19733eb36d8619713312f5604efef3502 upstream.

Without this patch, the values for ideality (register 0x4b) and ideality
selection mask (register 0x4c) are inverted.

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

---
drivers/hwmon/max6697.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/hwmon/max6697.c
+++ b/drivers/hwmon/max6697.c
@@ -605,12 +605,12 @@ static int max6697_init_chip(struct i2c_
if (ret < 0)
return ret;
ret = i2c_smbus_write_byte_data(client, MAX6581_REG_IDEALITY,
- pdata->ideality_mask >> 1);
+ pdata->ideality_value);
if (ret < 0)
return ret;
ret = i2c_smbus_write_byte_data(client,
MAX6581_REG_IDEALITY_SELECT,
- pdata->ideality_value);
+ pdata->ideality_mask >> 1);
if (ret < 0)
return ret;
}

2013-08-09 02:21:15

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 018/102] parisc: Fix interrupt routing for C8000 serial ports

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

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

From: Thomas Bogendoerfer <[email protected]>

commit dd5e6d6a3db09b16b7c222943977865eead88cc3 upstream.

We can't use dev->mod_index for selecting the interrupt routing entry,
because it's not an index into interrupt routing table. It will be even
wrong on a machine with 2 CPUs (4 cores). But all needed information is
contained in the PAT entries for the serial ports. mod[0] contains the
iosapic address and mod_info has some indications for the interrupt
input (at least it looks like it). This patch implements the searching
for the right iosapic and uses this interrupt input information.

Signed-off-by: Thomas Bogendoerfer <[email protected]>
Signed-off-by: Helge Deller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/parisc/include/asm/parisc-device.h | 3 ++
arch/parisc/kernel/inventory.c | 1
drivers/parisc/iosapic.c | 38 ++++++++++++++++++++++----------
drivers/tty/serial/8250/8250_gsc.c | 3 --
4 files changed, 32 insertions(+), 13 deletions(-)

--- a/arch/parisc/include/asm/parisc-device.h
+++ b/arch/parisc/include/asm/parisc-device.h
@@ -23,6 +23,7 @@ struct parisc_device {
/* generic info returned from pdc_pat_cell_module() */
unsigned long mod_info; /* PAT specific - Misc Module info */
unsigned long pmod_loc; /* physical Module location */
+ unsigned long mod0;
#endif
u64 dma_mask; /* DMA mask for I/O */
struct device dev;
@@ -61,4 +62,6 @@ parisc_get_drvdata(struct parisc_device

extern struct bus_type parisc_bus_type;

+int iosapic_serial_irq(struct parisc_device *dev);
+
#endif /*_ASM_PARISC_PARISC_DEVICE_H_*/
--- a/arch/parisc/kernel/inventory.c
+++ b/arch/parisc/kernel/inventory.c
@@ -211,6 +211,7 @@ pat_query_module(ulong pcell_loc, ulong
/* REVISIT: who is the consumer of this? not sure yet... */
dev->mod_info = pa_pdc_cell->mod_info; /* pass to PAT_GET_ENTITY() */
dev->pmod_loc = pa_pdc_cell->mod_location;
+ dev->mod0 = pa_pdc_cell->mod[0];

register_parisc_device(dev); /* advertise device */

--- a/drivers/parisc/iosapic.c
+++ b/drivers/parisc/iosapic.c
@@ -811,18 +811,28 @@ int iosapic_fixup_irq(void *isi_obj, str
return pcidev->irq;
}

-static struct iosapic_info *first_isi = NULL;
+static struct iosapic_info *iosapic_list;

#ifdef CONFIG_64BIT
-int iosapic_serial_irq(int num)
+int iosapic_serial_irq(struct parisc_device *dev)
{
- struct iosapic_info *isi = first_isi;
- struct irt_entry *irte = NULL; /* only used if PAT PDC */
+ struct iosapic_info *isi;
+ struct irt_entry *irte;
struct vector_info *vi;
- int isi_line; /* line used by device */
+ int cnt;
+ int intin;
+
+ intin = (dev->mod_info >> 24) & 15;

/* lookup IRT entry for isi/slot/pin set */
- irte = &irt_cell[num];
+ for (cnt = 0; cnt < irt_num_entry; cnt++) {
+ irte = &irt_cell[cnt];
+ if (COMPARE_IRTE_ADDR(irte, dev->mod0) &&
+ irte->dest_iosapic_intin == intin)
+ break;
+ }
+ if (cnt >= irt_num_entry)
+ return 0; /* no irq found, force polling */

DBG_IRT("iosapic_serial_irq(): irte %p %x %x %x %x %x %x %x %x\n",
irte,
@@ -834,11 +844,17 @@ int iosapic_serial_irq(int num)
irte->src_seg_id,
irte->dest_iosapic_intin,
(u32) irte->dest_iosapic_addr);
- isi_line = irte->dest_iosapic_intin;
+
+ /* search for iosapic */
+ for (isi = iosapic_list; isi; isi = isi->isi_next)
+ if (isi->isi_hpa == dev->mod0)
+ break;
+ if (!isi)
+ return 0; /* no iosapic found, force polling */

/* get vector info for this input line */
- vi = isi->isi_vector + isi_line;
- DBG_IRT("iosapic_serial_irq: line %d vi 0x%p\n", isi_line, vi);
+ vi = isi->isi_vector + intin;
+ DBG_IRT("iosapic_serial_irq: line %d vi 0x%p\n", iosapic_intin, vi);

/* If this IRQ line has already been setup, skip it */
if (vi->irte)
@@ -941,8 +957,8 @@ void *iosapic_register(unsigned long hpa
vip->irqline = (unsigned char) cnt;
vip->iosapic = isi;
}
- if (!first_isi)
- first_isi = isi;
+ isi->isi_next = iosapic_list;
+ iosapic_list = isi;
return isi;
}

--- a/drivers/tty/serial/8250/8250_gsc.c
+++ b/drivers/tty/serial/8250/8250_gsc.c
@@ -31,9 +31,8 @@ static int __init serial_init_chip(struc
int err;

#ifdef CONFIG_64BIT
- extern int iosapic_serial_irq(int cellnum);
if (!dev->irq && (dev->id.sversion == 0xad))
- dev->irq = iosapic_serial_irq(dev->mod_index-1);
+ dev->irq = iosapic_serial_irq(dev);
#endif

if (!dev->irq) {

2013-08-09 02:21:39

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 009/102] ARM: fix a cockup in 48be69a02 (ARM: move signal handlers into a vdso-like page)

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

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

From: Russell King <[email protected]>

commit e0d407564b532d978b03ceccebd224a05d02f111 upstream.

Unfortunately, I never committed the fix to a nasty oops which can
occur as a result of that commit:

------------[ cut here ]------------
kernel BUG at /home/olof/work/batch/include/linux/mm.h:414!
Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM
Modules linked in:
CPU: 0 PID: 490 Comm: killall5 Not tainted 3.11.0-rc3-00288-gabe0308 #53
task: e90acac0 ti: e9be8000 task.ti: e9be8000
PC is at special_mapping_fault+0xa4/0xc4
LR is at __do_fault+0x68/0x48c

This doesn't show up unless you do quite a bit of testing; a simple
boot test does not do this, so all my nightly tests were passing fine.

The reason for this is that install_special_mapping() expects the
page array to stick around, and as this was only inserting one page
which was stored on the kernel stack, that's why this was blowing up.

Reported-by: Olof Johansson <[email protected]>
Tested-by: Olof Johansson <[email protected]>
Signed-off-by: Russell King <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/arm/kernel/process.c | 9 +++++----
arch/arm/kernel/signal.c | 41 +++++++++++++++++++----------------------
2 files changed, 24 insertions(+), 26 deletions(-)

--- a/arch/arm/kernel/process.c
+++ b/arch/arm/kernel/process.c
@@ -478,17 +478,18 @@ const char *arch_vma_name(struct vm_area
"[sigpage]" : NULL;
}

+static struct page *signal_page;
extern struct page *get_signal_page(void);

int arch_setup_additional_pages(struct linux_binprm *bprm, int uses_interp)
{
struct mm_struct *mm = current->mm;
- struct page *page;
unsigned long addr;
int ret;

- page = get_signal_page();
- if (!page)
+ if (!signal_page)
+ signal_page = get_signal_page();
+ if (!signal_page)
return -ENOMEM;

down_write(&mm->mmap_sem);
@@ -500,7 +501,7 @@ int arch_setup_additional_pages(struct l

ret = install_special_mapping(mm, addr, PAGE_SIZE,
VM_READ | VM_EXEC | VM_MAYREAD | VM_MAYWRITE | VM_MAYEXEC,
- &page);
+ &signal_page);

if (ret == 0)
mm->context.sigpage = addr;
--- a/arch/arm/kernel/signal.c
+++ b/arch/arm/kernel/signal.c
@@ -609,35 +609,32 @@ do_work_pending(struct pt_regs *regs, un
return 0;
}

-static struct page *signal_page;
-
struct page *get_signal_page(void)
{
- if (!signal_page) {
- unsigned long ptr;
- unsigned offset;
- void *addr;
+ unsigned long ptr;
+ unsigned offset;
+ struct page *page;
+ void *addr;

- signal_page = alloc_pages(GFP_KERNEL, 0);
+ page = alloc_pages(GFP_KERNEL, 0);

- if (!signal_page)
- return NULL;
+ if (!page)
+ return NULL;

- addr = page_address(signal_page);
+ addr = page_address(page);

- /* Give the signal return code some randomness */
- offset = 0x200 + (get_random_int() & 0x7fc);
- signal_return_offset = offset;
+ /* Give the signal return code some randomness */
+ offset = 0x200 + (get_random_int() & 0x7fc);
+ signal_return_offset = offset;

- /*
- * Copy signal return handlers into the vector page, and
- * set sigreturn to be a pointer to these.
- */
- memcpy(addr + offset, sigreturn_codes, sizeof(sigreturn_codes));
+ /*
+ * Copy signal return handlers into the vector page, and
+ * set sigreturn to be a pointer to these.
+ */
+ memcpy(addr + offset, sigreturn_codes, sizeof(sigreturn_codes));

- ptr = (unsigned long)addr + offset;
- flush_icache_range(ptr, ptr + sizeof(sigreturn_codes));
- }
+ ptr = (unsigned long)addr + offset;
+ flush_icache_range(ptr, ptr + sizeof(sigreturn_codes));

- return signal_page;
+ return page;
}

2013-08-09 02:21:56

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 016/102] parisc: agp/parisc-agp: allow binding of user memory to the AGP GART

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

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

From: Alex Ivanov <[email protected]>

commit 06f0cce43a32bd2357cea1d8733bba48693d556b upstream.

Allow binding of user memory to the AGP GART on systems with HP
Quicksilver AGP bus. This resolves 'bind memory failed' error seen in
dmesg:

[29.365973] [TTM] AGP Bind memory failed.

[29.367030] [drm] Forcing AGP to PCI mode

The system doesn't more fail to bind the memory, and hence not falling
back to the PCI mode (if other failures aren't detected).

This is just a simple write down from the following patches:
agp/amd-k7: Allow binding user memory to the AGP GART
agp/hp-agp: Allow binding user memory to the AGP GART

Signed-off-by: Alex Ivanov <[email protected]>
Signed-off-by: Helge Deller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/char/agp/parisc-agp.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)

--- a/drivers/char/agp/parisc-agp.c
+++ b/drivers/char/agp/parisc-agp.c
@@ -129,7 +129,8 @@ parisc_agp_insert_memory(struct agp_memo
off_t j, io_pg_start;
int io_pg_count;

- if (type != 0 || mem->type != 0) {
+ if (type != mem->type ||
+ agp_bridge->driver->agp_type_to_mask_type(agp_bridge, type)) {
return -EINVAL;
}

@@ -175,7 +176,8 @@ parisc_agp_remove_memory(struct agp_memo
struct _parisc_agp_info *info = &parisc_agp_info;
int i, io_pg_start, io_pg_count;

- if (type != 0 || mem->type != 0) {
+ if (type != mem->type ||
+ agp_bridge->driver->agp_type_to_mask_type(agp_bridge, type)) {
return -EINVAL;
}


2013-08-09 02:22:18

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 015/102] powerpc: VPHN topology change updates all siblings

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

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

From: Robert Jennings <[email protected]>

commit 3be7db6ab45b21345386d1a466da133b19cde5e4 upstream.

When an associativity level change is found for one thread, the
siblings threads need to be updated as well. This is done today
for PRRN in stage_topology_update() but is missing for VPHN in
update_cpu_associativity_changes_mask(). This patch will correctly
update all thread siblings during a topology change.

Without this patch a topology update can result in a CPU in
init_sched_groups_power() getting stuck indefinitely in a loop.

This loop is built in build_sched_groups(). As a result of the thread
moving to a node separate from its siblings the struct sched_group will
have its next pointer set to point to itself rather than the sched_group
struct of the next thread. This happens because we have a domain without
the SD_OVERLAP flag, which is correct, and a topology that doesn't conform
with reality (threads on the same core assigned to different numa nodes).
When this list is traversed by init_sched_groups_power() it will reach
the thread's sched_group structure and loop indefinitely; the cpu will
be stuck at this point.

The bug was exposed when VPHN was enabled in commit b7abef0 (v3.9).

Reported-by: Jan Stancek <[email protected]>
Signed-off-by: Robert Jennings <[email protected]>
Signed-off-by: Benjamin Herrenschmidt <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/powerpc/include/asm/smp.h | 4 ++
arch/powerpc/mm/numa.c | 59 ++++++++++++++++++++++++++++++-----------
2 files changed, 48 insertions(+), 15 deletions(-)

--- a/arch/powerpc/include/asm/smp.h
+++ b/arch/powerpc/include/asm/smp.h
@@ -145,6 +145,10 @@ extern void __cpu_die(unsigned int cpu);
#define smp_setup_cpu_maps()
static inline void inhibit_secondary_onlining(void) {}
static inline void uninhibit_secondary_onlining(void) {}
+static inline const struct cpumask *cpu_sibling_mask(int cpu)
+{
+ return cpumask_of(cpu);
+}

#endif /* CONFIG_SMP */

--- a/arch/powerpc/mm/numa.c
+++ b/arch/powerpc/mm/numa.c
@@ -27,6 +27,7 @@
#include <linux/seq_file.h>
#include <linux/uaccess.h>
#include <linux/slab.h>
+#include <asm/cputhreads.h>
#include <asm/sparsemem.h>
#include <asm/prom.h>
#include <asm/smp.h>
@@ -1319,7 +1320,8 @@ static int update_cpu_associativity_chan
}
}
if (changed) {
- cpumask_set_cpu(cpu, changes);
+ cpumask_or(changes, changes, cpu_sibling_mask(cpu));
+ cpu = cpu_last_thread_sibling(cpu);
}
}

@@ -1427,7 +1429,7 @@ static int update_cpu_topology(void *dat
if (!data)
return -EINVAL;

- cpu = get_cpu();
+ cpu = smp_processor_id();

for (update = data; update; update = update->next) {
if (cpu != update->cpu)
@@ -1447,12 +1449,12 @@ static int update_cpu_topology(void *dat
*/
int arch_update_cpu_topology(void)
{
- unsigned int cpu, changed = 0;
+ unsigned int cpu, sibling, changed = 0;
struct topology_update_data *updates, *ud;
unsigned int associativity[VPHN_ASSOC_BUFSIZE] = {0};
cpumask_t updated_cpus;
struct device *dev;
- int weight, i = 0;
+ int weight, new_nid, i = 0;

weight = cpumask_weight(&cpu_associativity_changes_mask);
if (!weight)
@@ -1465,19 +1467,46 @@ int arch_update_cpu_topology(void)
cpumask_clear(&updated_cpus);

for_each_cpu(cpu, &cpu_associativity_changes_mask) {
- ud = &updates[i++];
- ud->cpu = cpu;
- vphn_get_associativity(cpu, associativity);
- ud->new_nid = associativity_to_nid(associativity);
-
- if (ud->new_nid < 0 || !node_online(ud->new_nid))
- ud->new_nid = first_online_node;
+ /*
+ * If siblings aren't flagged for changes, updates list
+ * will be too short. Skip on this update and set for next
+ * update.
+ */
+ if (!cpumask_subset(cpu_sibling_mask(cpu),
+ &cpu_associativity_changes_mask)) {
+ pr_info("Sibling bits not set for associativity "
+ "change, cpu%d\n", cpu);
+ cpumask_or(&cpu_associativity_changes_mask,
+ &cpu_associativity_changes_mask,
+ cpu_sibling_mask(cpu));
+ cpu = cpu_last_thread_sibling(cpu);
+ continue;
+ }

- ud->old_nid = numa_cpu_lookup_table[cpu];
- cpumask_set_cpu(cpu, &updated_cpus);
+ /* Use associativity from first thread for all siblings */
+ vphn_get_associativity(cpu, associativity);
+ new_nid = associativity_to_nid(associativity);
+ if (new_nid < 0 || !node_online(new_nid))
+ new_nid = first_online_node;
+
+ if (new_nid == numa_cpu_lookup_table[cpu]) {
+ cpumask_andnot(&cpu_associativity_changes_mask,
+ &cpu_associativity_changes_mask,
+ cpu_sibling_mask(cpu));
+ cpu = cpu_last_thread_sibling(cpu);
+ continue;
+ }

- if (i < weight)
- ud->next = &updates[i];
+ for_each_cpu(sibling, cpu_sibling_mask(cpu)) {
+ ud = &updates[i++];
+ ud->cpu = sibling;
+ ud->new_nid = new_nid;
+ ud->old_nid = numa_cpu_lookup_table[sibling];
+ cpumask_set_cpu(sibling, &updated_cpus);
+ if (i < weight)
+ ud->next = &updates[i];
+ }
+ cpu = cpu_last_thread_sibling(cpu);
}

stop_machine(update_cpu_topology, &updates[0], &updated_cpus);

2013-08-09 02:22:34

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 014/102] ARM: 7791/1: a.out: remove partial a.out support

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

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

From: Will Deacon <[email protected]>

commit acfdd4b1f7590d02e9bae3b73bdbbc4a31b05d38 upstream.

a.out support on ARM requires that argc, argv and envp are passed in
r0-r2 respectively, which requires hacking load_aout_binary to
prevent argc being clobbered by the return code. Whilst mainline kernels
do set the registers up in start_thread, the aout loader has never
carried the hack in mainline.

Initialising the registers in this way actually goes against the libc
expectations for ELF binaries, where argc, argv and envp are passed on
the stack, with r0 being used to hold a pointer to an exit function for
cleaning up after the dynamic linker if required. If the pointer is
NULL, then it is ignored. When execing an ELF binary, Linux currently
zeroes r0, then sets it to argc and then finally clobbers it with the
return value of the execve syscall, so we actually end up with:

r0 = 0
stack[0] = argc
r1 = stack[1] = argv
r2 = stack[2] = envp

libc treats r1 and r2 as undefined. The clobbering of r0 by sys_execve
works for user-spawned threads, but when executing an ELF binary from a
kernel thread (via call_usermodehelper), the execve is performed on the
ret_from_fork path, which restores r0 from the saved pt_regs, resulting
in argc being presented to the C library. This has horrible consequences
when the application exits, since we have an exit function registered
using argc, resulting in a jump to hyperspace.

This patch solves the problem by removing the partial a.out support from
arch/arm/ altogether.

Signed-off-by: Will Deacon <[email protected]>
Cc: Ashish Sangwan <[email protected]>
Signed-off-by: Russell King <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/arm/Kconfig | 1
arch/arm/include/asm/a.out-core.h | 45 --------------------------------------
arch/arm/include/asm/processor.h | 4 ---
arch/arm/include/uapi/asm/Kbuild | 1
arch/arm/include/uapi/asm/a.out.h | 34 ----------------------------
5 files changed, 85 deletions(-)

--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -19,7 +19,6 @@ config ARM
select GENERIC_STRNCPY_FROM_USER
select GENERIC_STRNLEN_USER
select HARDIRQS_SW_RESEND
- select HAVE_AOUT
select HAVE_ARCH_JUMP_LABEL if !XIP_KERNEL
select HAVE_ARCH_KGDB
select HAVE_ARCH_SECCOMP_FILTER
--- a/arch/arm/include/asm/a.out-core.h
+++ /dev/null
@@ -1,45 +0,0 @@
-/* a.out coredump register dumper
- *
- * Copyright (C) 2007 Red Hat, Inc. All Rights Reserved.
- * Written by David Howells ([email protected])
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public Licence
- * as published by the Free Software Foundation; either version
- * 2 of the Licence, or (at your option) any later version.
- */
-
-#ifndef _ASM_A_OUT_CORE_H
-#define _ASM_A_OUT_CORE_H
-
-#ifdef __KERNEL__
-
-#include <linux/user.h>
-#include <linux/elfcore.h>
-
-/*
- * fill in the user structure for an a.out core dump
- */
-static inline void aout_dump_thread(struct pt_regs *regs, struct user *dump)
-{
- struct task_struct *tsk = current;
-
- dump->magic = CMAGIC;
- dump->start_code = tsk->mm->start_code;
- dump->start_stack = regs->ARM_sp & ~(PAGE_SIZE - 1);
-
- dump->u_tsize = (tsk->mm->end_code - tsk->mm->start_code) >> PAGE_SHIFT;
- dump->u_dsize = (tsk->mm->brk - tsk->mm->start_data + PAGE_SIZE - 1) >> PAGE_SHIFT;
- dump->u_ssize = 0;
-
- memset(dump->u_debugreg, 0, sizeof(dump->u_debugreg));
-
- if (dump->start_stack < 0x04000000)
- dump->u_ssize = (0x04000000 - dump->start_stack) >> PAGE_SHIFT;
-
- dump->regs = *regs;
- dump->u_fpvalid = dump_fpu (regs, &dump->u_fp);
-}
-
-#endif /* __KERNEL__ */
-#endif /* _ASM_A_OUT_CORE_H */
--- a/arch/arm/include/asm/processor.h
+++ b/arch/arm/include/asm/processor.h
@@ -54,7 +54,6 @@ struct thread_struct {

#define start_thread(regs,pc,sp) \
({ \
- unsigned long *stack = (unsigned long *)sp; \
memset(regs->uregs, 0, sizeof(regs->uregs)); \
if (current->personality & ADDR_LIMIT_32BIT) \
regs->ARM_cpsr = USR_MODE; \
@@ -65,9 +64,6 @@ struct thread_struct {
regs->ARM_cpsr |= PSR_ENDSTATE; \
regs->ARM_pc = pc & ~1; /* pc */ \
regs->ARM_sp = sp; /* sp */ \
- regs->ARM_r2 = stack[2]; /* r2 (envp) */ \
- regs->ARM_r1 = stack[1]; /* r1 (argv) */ \
- regs->ARM_r0 = stack[0]; /* r0 (argc) */ \
nommu_start_thread(regs); \
})

--- a/arch/arm/include/uapi/asm/Kbuild
+++ b/arch/arm/include/uapi/asm/Kbuild
@@ -1,7 +1,6 @@
# UAPI Header export list
include include/uapi/asm-generic/Kbuild.asm

-header-y += a.out.h
header-y += byteorder.h
header-y += fcntl.h
header-y += hwcap.h
--- a/arch/arm/include/uapi/asm/a.out.h
+++ /dev/null
@@ -1,34 +0,0 @@
-#ifndef __ARM_A_OUT_H__
-#define __ARM_A_OUT_H__
-
-#include <linux/personality.h>
-#include <linux/types.h>
-
-struct exec
-{
- __u32 a_info; /* Use macros N_MAGIC, etc for access */
- __u32 a_text; /* length of text, in bytes */
- __u32 a_data; /* length of data, in bytes */
- __u32 a_bss; /* length of uninitialized data area for file, in bytes */
- __u32 a_syms; /* length of symbol table data in file, in bytes */
- __u32 a_entry; /* start address */
- __u32 a_trsize; /* length of relocation info for text, in bytes */
- __u32 a_drsize; /* length of relocation info for data, in bytes */
-};
-
-/*
- * This is always the same
- */
-#define N_TXTADDR(a) (0x00008000)
-
-#define N_TRSIZE(a) ((a).a_trsize)
-#define N_DRSIZE(a) ((a).a_drsize)
-#define N_SYMSIZE(a) ((a).a_syms)
-
-#define M_ARM 103
-
-#ifndef LIBRARY_START_TEXT
-#define LIBRARY_START_TEXT (0x00c00000)
-#endif
-
-#endif /* __A_OUT_GNU_H__ */

2013-08-09 02:22:51

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 011/102] powerpc/windfarm: Fix noisy slots-fan on Xserve (rm31)

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

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

From: Aaro Koskinen <[email protected]>

commit fe956a1d4081ce1a959f87df397a15e252201f10 upstream.

slots-fan on G5 Xserve is always running at full speed with windfarm_rm31
driver, resulting in a very high acoustic noise level. It seems the fan
parameters are incorrect, and have been copied from the Drive Bay fan
(RPM, not present on rm31) of the legacy therm_pm72 driver. This patch
changes the parameters to match the Slots fan (PWM) of therm_pm72. With
the patch, slots-fan speed drops from 99% to 19% during normal use,
and slots-temp settle to ~42'C.

Signed-off-by: Aaro Koskinen <[email protected]>
Signed-off-by: Benjamin Herrenschmidt <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/macintosh/windfarm_rm31.c | 18 +++++++++---------
1 file changed, 9 insertions(+), 9 deletions(-)

--- a/drivers/macintosh/windfarm_rm31.c
+++ b/drivers/macintosh/windfarm_rm31.c
@@ -439,15 +439,15 @@ static void backside_setup_pid(void)

/* Slots fan */
static const struct wf_pid_param slots_param = {
- .interval = 5,
- .history_len = 2,
- .gd = 30 << 20,
- .gp = 5 << 20,
- .gr = 0,
- .itarget = 40 << 16,
- .additive = 1,
- .min = 300,
- .max = 4000,
+ .interval = 1,
+ .history_len = 20,
+ .gd = 0,
+ .gp = 0,
+ .gr = 0x00100000,
+ .itarget = 3200000,
+ .additive = 0,
+ .min = 20,
+ .max = 100,
};

static void slots_fan_tick(void)

2013-08-09 02:22:50

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 013/102] ARM: 7790/1: Fix deferred mm switch on VIVT processors

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

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

From: Catalin Marinas <[email protected]>

commit bdae73cd374e28db544fdd9b77de689a36e3c129 upstream.

As of commit b9d4d42ad9 (ARM: Remove __ARCH_WANT_INTERRUPTS_ON_CTXSW on
pre-ARMv6 CPUs), the mm switching on VIVT processors is done in the
finish_arch_post_lock_switch() function to avoid whole cache flushing
with interrupts disabled. The need for deferred mm switch is stored as a
thread flag (TIF_SWITCH_MM). However, with preemption enabled, we can
have another thread switch before finish_arch_post_lock_switch(). If the
new thread has the same mm as the previous 'next' thread, the scheduler
will not call switch_mm() and the TIF_SWITCH_MM flag won't be set for
the new thread.

This patch moves the switch pending flag to the mm_context_t structure
since this is specific to the mm rather than thread.

Signed-off-by: Catalin Marinas <[email protected]>
Reported-by: Marc Kleine-Budde <[email protected]>
Tested-by: Marc Kleine-Budde <[email protected]>
Signed-off-by: Russell King <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/arm/include/asm/mmu.h | 2 ++
arch/arm/include/asm/mmu_context.h | 20 ++++++++++++++++----
arch/arm/include/asm/thread_info.h | 1 -
3 files changed, 18 insertions(+), 5 deletions(-)

--- a/arch/arm/include/asm/mmu.h
+++ b/arch/arm/include/asm/mmu.h
@@ -6,6 +6,8 @@
typedef struct {
#ifdef CONFIG_CPU_HAS_ASID
atomic64_t id;
+#else
+ int switch_pending;
#endif
unsigned int vmalloc_seq;
unsigned long sigpage;
--- a/arch/arm/include/asm/mmu_context.h
+++ b/arch/arm/include/asm/mmu_context.h
@@ -55,7 +55,7 @@ static inline void check_and_switch_cont
* on non-ASID CPUs, the old mm will remain valid until the
* finish_arch_post_lock_switch() call.
*/
- set_ti_thread_flag(task_thread_info(tsk), TIF_SWITCH_MM);
+ mm->context.switch_pending = 1;
else
cpu_switch_mm(mm->pgd, mm);
}
@@ -64,9 +64,21 @@ static inline void check_and_switch_cont
finish_arch_post_lock_switch
static inline void finish_arch_post_lock_switch(void)
{
- if (test_and_clear_thread_flag(TIF_SWITCH_MM)) {
- struct mm_struct *mm = current->mm;
- cpu_switch_mm(mm->pgd, mm);
+ struct mm_struct *mm = current->mm;
+
+ if (mm && mm->context.switch_pending) {
+ /*
+ * Preemption must be disabled during cpu_switch_mm() as we
+ * have some stateful cache flush implementations. Check
+ * switch_pending again in case we were preempted and the
+ * switch to this mm was already done.
+ */
+ preempt_disable();
+ if (mm->context.switch_pending) {
+ mm->context.switch_pending = 0;
+ cpu_switch_mm(mm->pgd, mm);
+ }
+ preempt_enable_no_resched();
}
}

--- a/arch/arm/include/asm/thread_info.h
+++ b/arch/arm/include/asm/thread_info.h
@@ -156,7 +156,6 @@ extern int vfp_restore_user_hwstate(stru
#define TIF_USING_IWMMXT 17
#define TIF_MEMDIE 18 /* is terminating due to OOM killer */
#define TIF_RESTORE_SIGMASK 20
-#define TIF_SWITCH_MM 22 /* deferred switch_mm */

#define _TIF_SIGPENDING (1 << TIF_SIGPENDING)
#define _TIF_NEED_RESCHED (1 << TIF_NEED_RESCHED)

2013-08-09 01:58:24

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 001/102] ARM: poison the vectors page

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

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

From: Russell King <[email protected]>

commit f928d4f2a86f46b030fa0850385b4391fc2b5918 upstream.

Fill the empty regions of the vectors page with an exception generating
instruction. This ensures that any inappropriate branch to the vector
page is appropriately trapped, rather than just encountering some code
to execute. (The vectors page was filled with zero before, which
corresponds with the "andeq r0, r0, r0" instruction - a no-op.)

Acked-by Nicolas Pitre <[email protected]>
Signed-off-by: Russell King <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

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

--- a/arch/arm/kernel/traps.c
+++ b/arch/arm/kernel/traps.c
@@ -817,10 +817,20 @@ void __init early_trap_init(void *vector
extern char __vectors_start[], __vectors_end[];
extern char __kuser_helper_start[], __kuser_helper_end[];
int kuser_sz = __kuser_helper_end - __kuser_helper_start;
+ unsigned i;

vectors_page = vectors_base;

/*
+ * Poison the vectors page with an undefined instruction. This
+ * instruction is chosen to be undefined for both ARM and Thumb
+ * ISAs. The Thumb version is an undefined instruction with a
+ * branch back to the undefined instruction.
+ */
+ for (i = 0; i < PAGE_SIZE / sizeof(u32); i++)
+ ((u32 *)vectors_base)[i] = 0xe7fddef1;
+
+ /*
* Copy the vectors, stubs and kuser helpers (in entry-armv.S)
* into the vector page, mapped at 0xffff0000, and ensure these
* are visible to the instruction stream.

2013-08-09 02:23:33

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 006/102] ARM: allow kuser helpers to be removed from the vector page

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

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

From: Russell King <[email protected]>

commit f6f91b0d9fd971c630cef908dde8fe8795aefbf8 upstream.

Provide a kernel configuration option to allow the kernel user helpers
to be removed from the vector page, thereby preventing their use with
ROP (return orientated programming) attacks. This option is only
visible for CPU architectures which natively support all the operations
which kernel user helpers would normally provide, and must be enabled
with caution.

Acked-by: Nicolas Pitre <[email protected]>
Signed-off-by: Russell King <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/arm/kernel/entry-armv.S | 3 +++
arch/arm/kernel/traps.c | 23 ++++++++++++++---------
arch/arm/mm/Kconfig | 34 ++++++++++++++++++++++++++++++++++
3 files changed, 51 insertions(+), 9 deletions(-)

--- a/arch/arm/kernel/entry-armv.S
+++ b/arch/arm/kernel/entry-armv.S
@@ -752,6 +752,7 @@ ENDPROC(__switch_to)
.endr
.endm

+#ifdef CONFIG_KUSER_HELPERS
.align 5
.globl __kuser_helper_start
__kuser_helper_start:
@@ -938,6 +939,8 @@ __kuser_helper_version: @ 0xffff0ffc
.globl __kuser_helper_end
__kuser_helper_end:

+#endif
+
THUMB( .thumb )

/*
--- a/arch/arm/kernel/traps.c
+++ b/arch/arm/kernel/traps.c
@@ -800,23 +800,32 @@ void __init trap_init(void)
return;
}

-static void __init kuser_get_tls_init(unsigned long vectors)
+#ifdef CONFIG_KUSER_HELPERS
+static void __init kuser_init(void *vectors)
{
+ extern char __kuser_helper_start[], __kuser_helper_end[];
+ int kuser_sz = __kuser_helper_end - __kuser_helper_start;
+
+ memcpy(vectors + 0x1000 - kuser_sz, __kuser_helper_start, kuser_sz);
+
/*
* vectors + 0xfe0 = __kuser_get_tls
* vectors + 0xfe8 = hardware TLS instruction at 0xffff0fe8
*/
if (tls_emu || has_tls_reg)
- memcpy((void *)vectors + 0xfe0, (void *)vectors + 0xfe8, 4);
+ memcpy(vectors + 0xfe0, vectors + 0xfe8, 4);
+}
+#else
+static void __init kuser_init(void *vectors)
+{
}
+#endif

void __init early_trap_init(void *vectors_base)
{
unsigned long vectors = (unsigned long)vectors_base;
extern char __stubs_start[], __stubs_end[];
extern char __vectors_start[], __vectors_end[];
- extern char __kuser_helper_start[], __kuser_helper_end[];
- int kuser_sz = __kuser_helper_end - __kuser_helper_start;
unsigned i;

vectors_page = vectors_base;
@@ -837,12 +846,8 @@ void __init early_trap_init(void *vector
*/
memcpy((void *)vectors, __vectors_start, __vectors_end - __vectors_start);
memcpy((void *)vectors + 0x1000, __stubs_start, __stubs_end - __stubs_start);
- memcpy((void *)vectors + 0x1000 - kuser_sz, __kuser_helper_start, kuser_sz);

- /*
- * Do processor specific fixups for the kuser helpers
- */
- kuser_get_tls_init(vectors);
+ kuser_init(vectors_base);

/*
* Copy signal return handlers into the vector page, and
--- a/arch/arm/mm/Kconfig
+++ b/arch/arm/mm/Kconfig
@@ -411,24 +411,28 @@ config CPU_32v3
select CPU_USE_DOMAINS if MMU
select NEEDS_SYSCALL_FOR_CMPXCHG if SMP
select TLS_REG_EMUL if SMP || !MMU
+ select NEED_KUSER_HELPERS

config CPU_32v4
bool
select CPU_USE_DOMAINS if MMU
select NEEDS_SYSCALL_FOR_CMPXCHG if SMP
select TLS_REG_EMUL if SMP || !MMU
+ select NEED_KUSER_HELPERS

config CPU_32v4T
bool
select CPU_USE_DOMAINS if MMU
select NEEDS_SYSCALL_FOR_CMPXCHG if SMP
select TLS_REG_EMUL if SMP || !MMU
+ select NEED_KUSER_HELPERS

config CPU_32v5
bool
select CPU_USE_DOMAINS if MMU
select NEEDS_SYSCALL_FOR_CMPXCHG if SMP
select TLS_REG_EMUL if SMP || !MMU
+ select NEED_KUSER_HELPERS

config CPU_32v6
bool
@@ -756,6 +760,7 @@ config CPU_BPREDICT_DISABLE

config TLS_REG_EMUL
bool
+ select NEED_KUSER_HELPERS
help
An SMP system using a pre-ARMv6 processor (there are apparently
a few prototypes like that in existence) and therefore access to
@@ -763,11 +768,40 @@ config TLS_REG_EMUL

config NEEDS_SYSCALL_FOR_CMPXCHG
bool
+ select NEED_KUSER_HELPERS
help
SMP on a pre-ARMv6 processor? Well OK then.
Forget about fast user space cmpxchg support.
It is just not possible.

+config NEED_KUSER_HELPERS
+ bool
+
+config KUSER_HELPERS
+ bool "Enable kuser helpers in vector page" if !NEED_KUSER_HELPERS
+ default y
+ help
+ Warning: disabling this option may break user programs.
+
+ Provide kuser helpers in the vector page. The kernel provides
+ helper code to userspace in read only form at a fixed location
+ in the high vector page to allow userspace to be independent of
+ the CPU type fitted to the system. This permits binaries to be
+ run on ARMv4 through to ARMv7 without modification.
+
+ However, the fixed address nature of these helpers can be used
+ by ROP (return orientated programming) authors when creating
+ exploits.
+
+ If all of the binaries and libraries which run on your platform
+ are built specifically for your platform, and make no use of
+ these helpers, then you can turn this option off. However,
+ when such an binary or library is run, it will receive a SIGILL
+ signal, which will terminate the program.
+
+ Say N here only if you are absolutely certain that you do not
+ need these helpers; otherwise, the safe option is to say Y.
+
config DMA_CACHE_RWFO
bool "Enable read/write for ownership DMA cache maintenance"
depends on CPU_V6K && SMP

2013-08-09 02:23:32

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 007/102] ARM: move signal handlers into a vdso-like page

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

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

From: Russell King <[email protected]>

commit 48be69a026b2c17350a5ef18a1959a919f60be7d upstream.

Move the signal handlers into a VDSO page rather than keeping them in
the vectors page. This allows us to place them randomly within this
page, and also map the page at a random location within userspace
further protecting these code fragments from ROP attacks. The new
VDSO page is also poisoned in the same way as the vector page.

Signed-off-by: Russell King <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/arm/include/asm/elf.h | 4 +++
arch/arm/include/asm/mmu.h | 1
arch/arm/kernel/process.c | 40 +++++++++++++++++++++++++++++++++---
arch/arm/kernel/signal.c | 50 +++++++++++++++++++++++++++++++++++++++------
arch/arm/kernel/signal.h | 12 ----------
arch/arm/kernel/traps.c | 9 --------
6 files changed, 86 insertions(+), 30 deletions(-)

--- a/arch/arm/include/asm/elf.h
+++ b/arch/arm/include/asm/elf.h
@@ -130,4 +130,8 @@ struct mm_struct;
extern unsigned long arch_randomize_brk(struct mm_struct *mm);
#define arch_randomize_brk arch_randomize_brk

+#define ARCH_HAS_SETUP_ADDITIONAL_PAGES 1
+struct linux_binprm;
+int arch_setup_additional_pages(struct linux_binprm *, int);
+
#endif
--- a/arch/arm/include/asm/mmu.h
+++ b/arch/arm/include/asm/mmu.h
@@ -8,6 +8,7 @@ typedef struct {
atomic64_t id;
#endif
unsigned int vmalloc_seq;
+ unsigned long sigpage;
} mm_context_t;

#ifdef CONFIG_CPU_HAS_ASID
--- a/arch/arm/kernel/process.c
+++ b/arch/arm/kernel/process.c
@@ -435,8 +435,8 @@ unsigned long arch_randomize_brk(struct
#ifdef CONFIG_MMU
/*
* The vectors page is always readable from user space for the
- * atomic helpers and the signal restart code. Insert it into the
- * gate_vma so that it is visible through ptrace and /proc/<pid>/mem.
+ * atomic helpers. Insert it into the gate_vma so that it is visible
+ * through ptrace and /proc/<pid>/mem.
*/
static struct vm_area_struct gate_vma = {
.vm_start = 0xffff0000,
@@ -468,6 +468,40 @@ int in_gate_area_no_mm(unsigned long add

const char *arch_vma_name(struct vm_area_struct *vma)
{
- return (vma == &gate_vma) ? "[vectors]" : NULL;
+ return (vma == &gate_vma) ? "[vectors]" :
+ (vma->vm_mm && vma->vm_start == vma->vm_mm->context.sigpage) ?
+ "[sigpage]" : NULL;
+}
+
+extern struct page *get_signal_page(void);
+
+int arch_setup_additional_pages(struct linux_binprm *bprm, int uses_interp)
+{
+ struct mm_struct *mm = current->mm;
+ struct page *page;
+ unsigned long addr;
+ int ret;
+
+ page = get_signal_page();
+ if (!page)
+ return -ENOMEM;
+
+ down_write(&mm->mmap_sem);
+ addr = get_unmapped_area(NULL, 0, PAGE_SIZE, 0, 0);
+ if (IS_ERR_VALUE(addr)) {
+ ret = addr;
+ goto up_fail;
+ }
+
+ ret = install_special_mapping(mm, addr, PAGE_SIZE,
+ VM_READ | VM_EXEC | VM_MAYREAD | VM_MAYWRITE | VM_MAYEXEC,
+ &page);
+
+ if (ret == 0)
+ mm->context.sigpage = addr;
+
+ up_fail:
+ up_write(&mm->mmap_sem);
+ return ret;
}
#endif
--- a/arch/arm/kernel/signal.c
+++ b/arch/arm/kernel/signal.c
@@ -8,6 +8,7 @@
* published by the Free Software Foundation.
*/
#include <linux/errno.h>
+#include <linux/random.h>
#include <linux/signal.h>
#include <linux/personality.h>
#include <linux/uaccess.h>
@@ -15,12 +16,11 @@

#include <asm/elf.h>
#include <asm/cacheflush.h>
+#include <asm/traps.h>
#include <asm/ucontext.h>
#include <asm/unistd.h>
#include <asm/vfp.h>

-#include "signal.h"
-
/*
* For ARM syscalls, we encode the syscall number into the instruction.
*/
@@ -40,11 +40,13 @@
#define SWI_THUMB_SIGRETURN (0xdf00 << 16 | 0x2700 | (__NR_sigreturn - __NR_SYSCALL_BASE))
#define SWI_THUMB_RT_SIGRETURN (0xdf00 << 16 | 0x2700 | (__NR_rt_sigreturn - __NR_SYSCALL_BASE))

-const unsigned long sigreturn_codes[7] = {
+static const unsigned long sigreturn_codes[7] = {
MOV_R7_NR_SIGRETURN, SWI_SYS_SIGRETURN, SWI_THUMB_SIGRETURN,
MOV_R7_NR_RT_SIGRETURN, SWI_SYS_RT_SIGRETURN, SWI_THUMB_RT_SIGRETURN,
};

+static unsigned long signal_return_offset;
+
#ifdef CONFIG_CRUNCH
static int preserve_crunch_context(struct crunch_sigframe __user *frame)
{
@@ -397,11 +399,14 @@ setup_return(struct pt_regs *regs, struc
return 1;

if (cpsr & MODE32_BIT) {
+ struct mm_struct *mm = current->mm;
/*
- * 32-bit code can use the new high-page
- * signal return code support.
+ * 32-bit code can use the signal return page
+ * except when the MPU has protected the vectors
+ * page from PL0
*/
- retcode = KERN_SIGRETURN_CODE + (idx << 2) + thumb;
+ retcode = mm->context.sigpage + signal_return_offset +
+ (idx << 2) + thumb;
} else {
/*
* Ensure that the instruction cache sees
@@ -603,3 +608,36 @@ do_work_pending(struct pt_regs *regs, un
} while (thread_flags & _TIF_WORK_MASK);
return 0;
}
+
+static struct page *signal_page;
+
+struct page *get_signal_page(void)
+{
+ if (!signal_page) {
+ unsigned long ptr;
+ unsigned offset;
+ void *addr;
+
+ signal_page = alloc_pages(GFP_KERNEL, 0);
+
+ if (!signal_page)
+ return NULL;
+
+ addr = page_address(signal_page);
+
+ /* Give the signal return code some randomness */
+ offset = 0x200 + (get_random_int() & 0x7fc);
+ signal_return_offset = offset;
+
+ /*
+ * Copy signal return handlers into the vector page, and
+ * set sigreturn to be a pointer to these.
+ */
+ memcpy(addr + offset, sigreturn_codes, sizeof(sigreturn_codes));
+
+ ptr = (unsigned long)addr + offset;
+ flush_icache_range(ptr, ptr + sizeof(sigreturn_codes));
+ }
+
+ return signal_page;
+}
--- a/arch/arm/kernel/signal.h
+++ /dev/null
@@ -1,12 +0,0 @@
-/*
- * linux/arch/arm/kernel/signal.h
- *
- * Copyright (C) 2005-2009 Russell King.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-#define KERN_SIGRETURN_CODE (CONFIG_VECTORS_BASE + 0x00000500)
-
-extern const unsigned long sigreturn_codes[7];
--- a/arch/arm/kernel/traps.c
+++ b/arch/arm/kernel/traps.c
@@ -35,8 +35,6 @@
#include <asm/tls.h>
#include <asm/system_misc.h>

-#include "signal.h"
-
static const char *handler[]= { "prefetch abort", "data abort", "address exception", "interrupt" };

void *vectors_page;
@@ -849,13 +847,6 @@ void __init early_trap_init(void *vector

kuser_init(vectors_base);

- /*
- * Copy signal return handlers into the vector page, and
- * set sigreturn to be a pointer to these.
- */
- memcpy((void *)(vectors + KERN_SIGRETURN_CODE - CONFIG_VECTORS_BASE),
- sigreturn_codes, sizeof(sigreturn_codes));
-
flush_icache_range(vectors, vectors + PAGE_SIZE * 2);
modify_domain(DOMAIN_USER, DOMAIN_CLIENT);
}

2013-08-09 02:24:12

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 004/102] ARM: use linker magic for vectors and vector stubs

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

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

From: Russell King <[email protected]>

commit b9b32bf70f2fb710b07c94e13afbc729afe221da upstream.

Use linker magic to create the vectors and vector stubs: we can tell the
linker to place them at an appropriate VMA, but keep the LMA within the
kernel. This gets rid of some unnecessary symbol manipulation, and
have the linker calculate the relocations appropriately.

Acked-by: Nicolas Pitre <[email protected]>
Signed-off-by: Russell King <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/arm/kernel/entry-armv.S | 28 ++++++++++------------------
arch/arm/kernel/vmlinux.lds.S | 17 +++++++++++++++++
2 files changed, 27 insertions(+), 18 deletions(-)

--- a/arch/arm/kernel/entry-armv.S
+++ b/arch/arm/kernel/entry-armv.S
@@ -992,7 +992,7 @@ ENDPROC(vector_\name)
1:
.endm

- .globl __stubs_start
+ .section .stubs, "ax", %progbits
__stubs_start:
@ This must be the first word
.word vector_swi
@@ -1119,24 +1119,16 @@ vector_addrexcptn:
vector_fiq:
subs pc, lr, #4

- .globl __stubs_end
-__stubs_end:
-
- .equ stubs_offset, __vectors_start + 0x1000 - __stubs_start
-
- .globl __vectors_start
+ .section .vectors, "ax", %progbits
__vectors_start:
- W(b) vector_rst + stubs_offset
- W(b) vector_und + stubs_offset
- W(ldr) pc, .LCvswi + stubs_offset
- W(b) vector_pabt + stubs_offset
- W(b) vector_dabt + stubs_offset
- W(b) vector_addrexcptn + stubs_offset
- W(b) vector_irq + stubs_offset
- W(b) vector_fiq + stubs_offset
-
- .globl __vectors_end
-__vectors_end:
+ W(b) vector_rst
+ W(b) vector_und
+ W(ldr) pc, __vectors_start + 0x1000
+ W(b) vector_pabt
+ W(b) vector_dabt
+ W(b) vector_addrexcptn
+ W(b) vector_irq
+ W(b) vector_fiq

.data

--- a/arch/arm/kernel/vmlinux.lds.S
+++ b/arch/arm/kernel/vmlinux.lds.S
@@ -152,6 +152,23 @@ SECTIONS
. = ALIGN(PAGE_SIZE);
__init_begin = .;
#endif
+ /*
+ * The vectors and stubs are relocatable code, and the
+ * only thing that matters is their relative offsets
+ */
+ __vectors_start = .;
+ .vectors 0 : AT(__vectors_start) {
+ *(.vectors)
+ }
+ . = __vectors_start + SIZEOF(.vectors);
+ __vectors_end = .;
+
+ __stubs_start = .;
+ .stubs 0x1000 : AT(__stubs_start) {
+ *(.stubs)
+ }
+ . = __stubs_start + SIZEOF(.stubs);
+ __stubs_end = .;

INIT_TEXT_SECTION(8)
.exit.text : {

2013-08-09 02:24:36

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 003/102] ARM: move vector stubs

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

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

From: Russell King <[email protected]>

commit 19accfd373847ac3d10623c5d20f948846299741 upstream.

Move the machine vector stubs into the page above the vector page,
which we can prevent from being visible to userspace. Also move
the reset stub, and place the swi vector at a location that the
'ldr' can get to it.

This hides pointers into the kernel which could give valuable
information to attackers, and reduces the number of exploitable
instructions at a fixed address.

Acked-by: Nicolas Pitre <[email protected]>
Signed-off-by: Russell King <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/arm/Kconfig | 3 +-
arch/arm/kernel/entry-armv.S | 50 ++++++++++++++++++++-----------------------
arch/arm/kernel/traps.c | 4 +--
arch/arm/mm/mmu.c | 10 +++++++-
4 files changed, 37 insertions(+), 30 deletions(-)

--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -213,7 +213,8 @@ config VECTORS_BASE
default DRAM_BASE if REMAP_VECTORS_TO_RAM
default 0x00000000
help
- The base address of exception vectors.
+ The base address of exception vectors. This must be two pages
+ in size.

config ARM_PATCH_PHYS_VIRT
bool "Patch physical to virtual translations at runtime" if EMBEDDED
--- a/arch/arm/kernel/entry-armv.S
+++ b/arch/arm/kernel/entry-armv.S
@@ -943,9 +943,9 @@ __kuser_helper_end:
/*
* Vector stubs.
*
- * This code is copied to 0xffff0200 so we can use branches in the
- * vectors, rather than ldr's. Note that this code must not
- * exceed 0x300 bytes.
+ * This code is copied to 0xffff1000 so we can use branches in the
+ * vectors, rather than ldr's. Note that this code must not exceed
+ * a page size.
*
* Common stub entry macro:
* Enter in IRQ mode, spsr = SVC/USR CPSR, lr = SVC/USR PC
@@ -994,6 +994,15 @@ ENDPROC(vector_\name)

.globl __stubs_start
__stubs_start:
+ @ This must be the first word
+ .word vector_swi
+
+vector_rst:
+ ARM( swi SYS_ERROR0 )
+ THUMB( svc #0 )
+ THUMB( nop )
+ b vector_und
+
/*
* Interrupt dispatcher
*/
@@ -1088,6 +1097,16 @@ __stubs_start:
.align 5

/*=============================================================================
+ * Address exception handler
+ *-----------------------------------------------------------------------------
+ * These aren't too critical.
+ * (they're not supposed to happen, and won't happen in 32-bit data mode).
+ */
+
+vector_addrexcptn:
+ b vector_addrexcptn
+
+/*=============================================================================
* Undefined FIQs
*-----------------------------------------------------------------------------
* Enter in FIQ mode, spsr = ANY CPSR, lr = ANY PC
@@ -1100,35 +1119,14 @@ __stubs_start:
vector_fiq:
subs pc, lr, #4

-/*=============================================================================
- * Address exception handler
- *-----------------------------------------------------------------------------
- * These aren't too critical.
- * (they're not supposed to happen, and won't happen in 32-bit data mode).
- */
-
-vector_addrexcptn:
- b vector_addrexcptn
-
-/*
- * We group all the following data together to optimise
- * for CPUs with separate I & D caches.
- */
- .align 5
-
-.LCvswi:
- .word vector_swi
-
.globl __stubs_end
__stubs_end:

- .equ stubs_offset, __vectors_start + 0x200 - __stubs_start
+ .equ stubs_offset, __vectors_start + 0x1000 - __stubs_start

.globl __vectors_start
__vectors_start:
- ARM( swi SYS_ERROR0 )
- THUMB( svc #0 )
- THUMB( nop )
+ W(b) vector_rst + stubs_offset
W(b) vector_und + stubs_offset
W(ldr) pc, .LCvswi + stubs_offset
W(b) vector_pabt + stubs_offset
--- a/arch/arm/kernel/traps.c
+++ b/arch/arm/kernel/traps.c
@@ -836,7 +836,7 @@ void __init early_trap_init(void *vector
* are visible to the instruction stream.
*/
memcpy((void *)vectors, __vectors_start, __vectors_end - __vectors_start);
- memcpy((void *)vectors + 0x200, __stubs_start, __stubs_end - __stubs_start);
+ memcpy((void *)vectors + 0x1000, __stubs_start, __stubs_end - __stubs_start);
memcpy((void *)vectors + 0x1000 - kuser_sz, __kuser_helper_start, kuser_sz);

/*
@@ -851,6 +851,6 @@ void __init early_trap_init(void *vector
memcpy((void *)(vectors + KERN_SIGRETURN_CODE - CONFIG_VECTORS_BASE),
sigreturn_codes, sizeof(sigreturn_codes));

- flush_icache_range(vectors, vectors + PAGE_SIZE);
+ flush_icache_range(vectors, vectors + PAGE_SIZE * 2);
modify_domain(DOMAIN_USER, DOMAIN_CLIENT);
}
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -1175,7 +1175,7 @@ static void __init devicemaps_init(struc
/*
* Allocate the vector page early.
*/
- vectors = early_alloc(PAGE_SIZE);
+ vectors = early_alloc(PAGE_SIZE * 2);

early_trap_init(vectors);

@@ -1225,10 +1225,18 @@ static void __init devicemaps_init(struc

if (!vectors_high()) {
map.virtual = 0;
+ map.length = PAGE_SIZE * 2;
map.type = MT_LOW_VECTORS;
create_mapping(&map);
}

+ /* Now create a kernel read-only mapping */
+ map.pfn += 1;
+ map.virtual = 0xffff0000 + PAGE_SIZE;
+ map.length = PAGE_SIZE;
+ map.type = MT_LOW_VECTORS;
+ create_mapping(&map);
+
/*
* Ask the machine support to map in the statically mapped devices.
*/

2013-08-09 02:25:19

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 002/102] ARM: poison memory between kuser helpers

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

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

From: Russell King <[email protected]>

commit 5b43e7a383d69381ffe53423e46dd0fafae07da3 upstream.

Poison the memory between each kuser helper. This ensures that any
branch between the kuser helpers will be appropriately trapped.

Acked-by: Nicolas Pitre <[email protected]>
Signed-off-by: Russell King <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/arm/kernel/entry-armv.S | 25 ++++++++++++++++---------
1 file changed, 16 insertions(+), 9 deletions(-)

--- a/arch/arm/kernel/entry-armv.S
+++ b/arch/arm/kernel/entry-armv.S
@@ -741,6 +741,17 @@ ENDPROC(__switch_to)
#endif
.endm

+ .macro kuser_pad, sym, size
+ .if (. - \sym) & 3
+ .rept 4 - (. - \sym) & 3
+ .byte 0
+ .endr
+ .endif
+ .rept (\size - (. - \sym)) / 4
+ .word 0xe7fddef1
+ .endr
+ .endm
+
.align 5
.globl __kuser_helper_start
__kuser_helper_start:
@@ -831,18 +842,13 @@ kuser_cmpxchg64_fixup:
#error "incoherent kernel configuration"
#endif

- /* pad to next slot */
- .rept (16 - (. - __kuser_cmpxchg64)/4)
- .word 0
- .endr
-
- .align 5
+ kuser_pad __kuser_cmpxchg64, 64

__kuser_memory_barrier: @ 0xffff0fa0
smp_dmb arm
usr_ret lr

- .align 5
+ kuser_pad __kuser_memory_barrier, 32

__kuser_cmpxchg: @ 0xffff0fc0

@@ -915,13 +921,14 @@ kuser_cmpxchg32_fixup:

#endif

- .align 5
+ kuser_pad __kuser_cmpxchg, 32

__kuser_get_tls: @ 0xffff0fe0
ldr r0, [pc, #(16 - 8)] @ read TLS, set in kuser_get_tls_init
usr_ret lr
mrc p15, 0, r0, c13, c0, 3 @ 0xffff0fe8 hardware TLS code
- .rep 4
+ kuser_pad __kuser_get_tls, 16
+ .rep 3
.word 0 @ 0xffff0ff0 software TLS value, then
.endr @ pad up to __kuser_helper_version


2013-08-09 04:13:13

by Stefan Lippers-Hollmann

[permalink] [raw]
Subject: Re: [ 000/102] 3.10.6-stable review

Hi

On Friday 09 August 2013, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.10.6 release.
[…]
> The whole patch series can be found in one patch at:
> kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.10.6-rc1.gz
[…]

There appears to be a problem with the mirroring (not pushed?):

$ LANG= wget kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.10.6-rc1.gz
--2013-08-09 06:05:02-- http://kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.10.6-rc1.gz
Resolving kernel.org (kernel.org)... 149.20.4.69, 198.145.20.140
Connecting to kernel.org (kernel.org)|149.20.4.69|:80... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://www.kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.10.6-rc1.gz [following]
--2013-08-09 06:05:02-- https://www.kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.10.6-rc1.gz
Resolving http://www.kernel.org (http://www.kernel.org)... 198.145.20.140, 149.20.4.69
Connecting to http://www.kernel.org (http://www.kernel.org)|198.145.20.140|:443... connected.
HTTP request sent, awaiting response... 404 Not Found
2013-08-09 06:05:06 ERROR 404: Not Found.

The other -stable patches of this round
kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.4.57-rc1.gz
and
kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.0.90-rc1.gz
appear to be missing as well.

Using the current queue-3.10/series from
git://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git
builds and works fine on x86_64 and i386.

Regards
Stefan Lippers-Hollmann

2013-08-09 04:26:24

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [ 000/102] 3.10.6-stable review

On Fri, Aug 09, 2013 at 06:13:02AM +0200, Stefan Lippers-Hollmann wrote:
> Hi
>
> On Friday 09 August 2013, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 3.10.6 release.
> […]
> > The whole patch series can be found in one patch at:
> > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.10.6-rc1.gz
> […]
>
> There appears to be a problem with the mirroring (not pushed?):
>
> $ LANG= wget kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.10.6-rc1.gz
> --2013-08-09 06:05:02-- http://kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.10.6-rc1.gz
> Resolving kernel.org (kernel.org)... 149.20.4.69, 198.145.20.140
> Connecting to kernel.org (kernel.org)|149.20.4.69|:80... connected.
> HTTP request sent, awaiting response... 301 Moved Permanently
> Location: https://www.kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.10.6-rc1.gz [following]
> --2013-08-09 06:05:02-- https://www.kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.10.6-rc1.gz
> Resolving http://www.kernel.org (http://www.kernel.org)... 198.145.20.140, 149.20.4.69
> Connecting to http://www.kernel.org (http://www.kernel.org)|198.145.20.140|:443... connected.
> HTTP request sent, awaiting response... 404 Not Found
> 2013-08-09 06:05:06 ERROR 404: Not Found.
>
> The other -stable patches of this round
> kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.4.57-rc1.gz
> and
> kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.0.90-rc1.gz
> appear to be missing as well.

Yes, something up with the kernel.org backend, I have a support ticket
already opened up on this. Due to different timezones, it might take 12
hours or so before people wake up, so please be patient.

> Using the current queue-3.10/series from
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git
> builds and works fine on x86_64 and i386.

That's good to hear, thanks for testing and letting me know.

greg k-h

2013-08-09 04:29:30

by Stefan Lippers-Hollmann

[permalink] [raw]
Subject: Re: [ 008/102] ARM: make vectors page inaccessible from userspace

On Friday 09 August 2013, Greg Kroah-Hartman wrote:
> 3.10-stable review patch. If anyone has any objections, please let me know.
>
> ------------------
>
> From: Russell King <[email protected]>
>
> commit a5463cd3435475386cbbe7b06e01292ac169d36f upstream.
>
> If kuser helpers are not provided by the kernel, disable user access to
> the vectors page. With the kuser helpers gone, there is no reason for
> this page to be visible to userspace.
>
> Signed-off-by: Russell King <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>


If I read Russell King's response in

http://www.spinics.net/lists/stable/msg16792.html
Message-ID: <[email protected]>

correctly, this patch might not be wanted for -stable; this only
affects queue-3.10 at the moment.

Regards
Stefan Lippers-Hollmann

2013-08-09 04:44:58

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [ 008/102] ARM: make vectors page inaccessible from userspace

On Fri, Aug 09, 2013 at 06:29:17AM +0200, Stefan Lippers-Hollmann wrote:
> On Friday 09 August 2013, Greg Kroah-Hartman wrote:
> > 3.10-stable review patch. If anyone has any objections, please let me know.
> >
> > ------------------
> >
> > From: Russell King <[email protected]>
> >
> > commit a5463cd3435475386cbbe7b06e01292ac169d36f upstream.
> >
> > If kuser helpers are not provided by the kernel, disable user access to
> > the vectors page. With the kuser helpers gone, there is no reason for
> > this page to be visible to userspace.
> >
> > Signed-off-by: Russell King <[email protected]>
> > Signed-off-by: Greg Kroah-Hartman <[email protected]>
>
>
> If I read Russell King's response in
>
> http://www.spinics.net/lists/stable/msg16792.html
> Message-ID: <[email protected]>
>
> correctly, this patch might not be wanted for -stable; this only
> affects queue-3.10 at the moment.

Yes, I know there's a build warning/error here, but it only affects no
mmu systems, right? I'll pick up the fix that hits Linus's tree for
this when it gets there.

thanks,

greg k-h

2013-08-09 06:57:54

by Guenter Roeck

[permalink] [raw]
Subject: Re: [ 000/102] 3.10.6-stable review

On 08/08/2013 06:56 PM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.10.6 release.
> There are 102 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sun Aug 11 01:46:31 UTC 2013.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.10.6-rc1.gz
> and the diffstat can be found below.
>

Cross build results:
Total builds: 69 Total build errors: 2

Details:
http://server.roeck-us.net:8010/builders/stable-queue-3.10/builds/47/steps/shell/logs/stdio/text

Same results as before, except that I dropped a couple of builds and added some others.

The failing builds are arm:allmodconfig and mips:allmodconfig.
For both, the errors don't exist in mainline and should be trivial to fix in case anyone is interested.

arm:
FATAL: modpost: GPL-incompatible module bcm2835-rng.ko uses GPL-only symbol 'platform_driver_unregister'

[This one has been fixed upstream with commit 22e8099f4f6621b8d165e238cdef2a1cf655e159. Might be worthwhile
adding it to -stable]

mips:
drivers/net/ethernet/3com/3c59x.c:1031:2: error: implicit declaration of function 'pci_iomap'
drivers/net/ethernet/3com/3c59x.c:1044:3: error: implicit declaration of function 'pci_iounmap'

[no idea why this works upstream]

Guenter

2013-08-09 07:55:12

by Hedberg, Johan

[permalink] [raw]
Subject: Re: [ 045/102] Bluetooth: Fix invalid length check in l2cap_information_rsp()

Hi Greg,

On Thu, Aug 08, 2013, Greg Kroah-Hartman wrote:
> 3.10-stable review patch. If anyone has any objections, please let me know.
>
> ------------------
>
> From: Jaganath Kanakkassery <[email protected]>
>
> commit da9910ac4a816b4340944c78d94c02a35527db46 upstream.
>
> The length check is invalid since the length varies with type of
> info response.
>
> This was introduced by the commit cb3b3152b2f5939d67005cff841a1ca748b19888
>
> Because of this, l2cap info rsp is not handled and command reject is sent.
>
> > ACL data: handle 11 flags 0x02 dlen 16
> L2CAP(s): Info rsp: type 2 result 0
> Extended feature mask 0x00b8
> Enhanced Retransmission mode
> Streaming mode
> FCS Option
> Fixed Channels
> < ACL data: handle 11 flags 0x00 dlen 10
> L2CAP(s): Command rej: reason 0
> Command not understood
>
> Signed-off-by: Jaganath Kanakkassery <[email protected]>
> Signed-off-by: Chan-Yeol Park <[email protected]>
> Acked-by: Johan Hedberg <[email protected]>
> Signed-off-by: Gustavo Padovan <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
>
> ---
> net/bluetooth/l2cap_core.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> --- a/net/bluetooth/l2cap_core.c
> +++ b/net/bluetooth/l2cap_core.c
> @@ -4240,7 +4240,7 @@ static inline int l2cap_disconnect_rsp(s
> u16 dcid, scid;
> struct l2cap_chan *chan;
>
> - if (cmd_len != sizeof(*rsp))
> + if (cmd_len < sizeof(*rsp))
> return -EPROTO;
>
> scid = __le16_to_cpu(rsp->scid);

This patch is already in 3.10 so there should be no need to try to
backport it (not to mention that this backport itself is incorrect in
that it modifies l2cap_disconnect_rsp whereas the original patch
modifies l2cap_information_rsp).

For whatever reason this commit seems to exist twice in Linus' tree: once
before the v3.10 tag with id 3f6fa3d489e127ca5a5b298eabac3ff5dbe0e112 and
once after the v3.10 tag with id da9910ac4a816b4340944c78d94c02a35527db46
(which is the upstream commit id referenced by your commit message).

Johan

2013-08-09 14:42:29

by Shuah Khan

[permalink] [raw]
Subject: Re: [ 000/102] 3.10.6-stable review

On 08/09/2013 07:54 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.10.6 release.
> There are 102 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sun Aug 11 01:46:31 UTC 2013.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.10.6-rc1.gz
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>

I don't see the new stable release patches on

http://www.kernel.org/pub/linux/kernel/v3.0/stable-review/

Others were able to download last night as I can see from the test
responses. Something must have happened. Tried accessing with ftp client
as well.

-- Shuah

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

2013-08-09 19:10:08

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [ 000/102] 3.10.6-stable review

On Fri, Aug 09, 2013 at 02:42:24PM +0000, Shuah Khan wrote:
> On 08/09/2013 07:54 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 3.10.6 release.
> > There are 102 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Sun Aug 11 01:46:31 UTC 2013.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.10.6-rc1.gz
> > and the diffstat can be found below.
> >
> > thanks,
> >
> > greg k-h
> >
>
> I don't see the new stable release patches on
>
> http://www.kernel.org/pub/linux/kernel/v3.0/stable-review/
>
> Others were able to download last night as I can see from the test
> responses. Something must have happened. Tried accessing with ftp client
> as well.

No, the patches never made it there, I think people were testing based
on the git tree.

kernel.org is now fixed, and the patches should be there within a few
minutes.

thanks,

greg k-h

2013-08-09 19:11:33

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [ 000/102] 3.10.6-stable review

On Thu, Aug 08, 2013 at 11:57:55PM -0700, Guenter Roeck wrote:
> On 08/08/2013 06:56 PM, Greg Kroah-Hartman wrote:
> >This is the start of the stable review cycle for the 3.10.6 release.
> >There are 102 patches in this series, all will be posted as a response
> >to this one. If anyone has any issues with these being applied, please
> >let me know.
> >
> >Responses should be made by Sun Aug 11 01:46:31 UTC 2013.
> >Anything received after that time might be too late.
> >
> >The whole patch series can be found in one patch at:
> > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.10.6-rc1.gz
> >and the diffstat can be found below.
> >
>
> Cross build results:
> Total builds: 69 Total build errors: 2
>
> Details:
> http://server.roeck-us.net:8010/builders/stable-queue-3.10/builds/47/steps/shell/logs/stdio/text
>
> Same results as before, except that I dropped a couple of builds and added some others.

Thanks for testing.

> The failing builds are arm:allmodconfig and mips:allmodconfig.
> For both, the errors don't exist in mainline and should be trivial to fix in case anyone is interested.
>
> arm:
> FATAL: modpost: GPL-incompatible module bcm2835-rng.ko uses GPL-only symbol 'platform_driver_unregister'
>
> [This one has been fixed upstream with commit 22e8099f4f6621b8d165e238cdef2a1cf655e159. Might be worthwhile
> adding it to -stable]

Yes, I've now queued it up, thanks.

> mips:
> drivers/net/ethernet/3com/3c59x.c:1031:2: error: implicit declaration of function 'pci_iomap'
> drivers/net/ethernet/3com/3c59x.c:1044:3: error: implicit declaration of function 'pci_iounmap'
>
> [no idea why this works upstream]

Odd. If someone cares about MIPS I hope I'll get a fix for it :)

thanks,

greg k-h

2013-08-09 19:12:33

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [ 045/102] Bluetooth: Fix invalid length check in l2cap_information_rsp()

On Fri, Aug 09, 2013 at 10:54:58AM +0300, Johan Hedberg wrote:
> Hi Greg,
>
> On Thu, Aug 08, 2013, Greg Kroah-Hartman wrote:
> > 3.10-stable review patch. If anyone has any objections, please let me know.
> >
> > ------------------
> >
> > From: Jaganath Kanakkassery <[email protected]>
> >
> > commit da9910ac4a816b4340944c78d94c02a35527db46 upstream.
> >
> > The length check is invalid since the length varies with type of
> > info response.
> >
> > This was introduced by the commit cb3b3152b2f5939d67005cff841a1ca748b19888
> >
> > Because of this, l2cap info rsp is not handled and command reject is sent.
> >
> > > ACL data: handle 11 flags 0x02 dlen 16
> > L2CAP(s): Info rsp: type 2 result 0
> > Extended feature mask 0x00b8
> > Enhanced Retransmission mode
> > Streaming mode
> > FCS Option
> > Fixed Channels
> > < ACL data: handle 11 flags 0x00 dlen 10
> > L2CAP(s): Command rej: reason 0
> > Command not understood
> >
> > Signed-off-by: Jaganath Kanakkassery <[email protected]>
> > Signed-off-by: Chan-Yeol Park <[email protected]>
> > Acked-by: Johan Hedberg <[email protected]>
> > Signed-off-by: Gustavo Padovan <[email protected]>
> > Signed-off-by: Greg Kroah-Hartman <[email protected]>
> >
> > ---
> > net/bluetooth/l2cap_core.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > --- a/net/bluetooth/l2cap_core.c
> > +++ b/net/bluetooth/l2cap_core.c
> > @@ -4240,7 +4240,7 @@ static inline int l2cap_disconnect_rsp(s
> > u16 dcid, scid;
> > struct l2cap_chan *chan;
> >
> > - if (cmd_len != sizeof(*rsp))
> > + if (cmd_len < sizeof(*rsp))
> > return -EPROTO;
> >
> > scid = __le16_to_cpu(rsp->scid);
>
> This patch is already in 3.10 so there should be no need to try to
> backport it (not to mention that this backport itself is incorrect in
> that it modifies l2cap_disconnect_rsp whereas the original patch
> modifies l2cap_information_rsp).
>
> For whatever reason this commit seems to exist twice in Linus' tree: once
> before the v3.10 tag with id 3f6fa3d489e127ca5a5b298eabac3ff5dbe0e112 and
> once after the v3.10 tag with id da9910ac4a816b4340944c78d94c02a35527db46
> (which is the upstream commit id referenced by your commit message).

Thanks, this came into Linus's tree twice, I missed that. I've now
dropped this from the 3.10-stable queue.

greg k-h

2013-08-09 19:20:37

by Willy Tarreau

[permalink] [raw]
Subject: Re: [ 000/102] 3.10.6-stable review

Hi Greg,

On Thu, Aug 08, 2013 at 06:56:36PM -0700, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.10.6 release.
> There are 102 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.

Just checked on my OpenBlocks AX3 (dual-core ARMv7 in thumbs mode),
everything seems OK, I did not even notice any performance regression
compared to 3.10.5 on syscall intensive workloads with the recent
changes. I'm sure that I'm using the kuser helpers page since the
system doesn't boot without. Also I did observe minor changes in
/proc/self/maps, but I don't think they should have any impact, so
all in all it's OK :

3.10.6-rc1:
root@ax3:~# cat /proc/self/maps
00008000-00014000 r-xp 00000000 01:00 258 /bin/cat
0001c000-0001d000 rw-p 0000c000 01:00 258 /bin/cat
0001d000-0003e000 rw-p 00000000 00:00 0 [vectors]
b6ea6000-b6fc8000 r-xp 00000000 01:00 638 /lib/libc-2.17.so
b6fc8000-b6fcf000 ---p 00122000 01:00 638 /lib/libc-2.17.so
b6fcf000-b6fd1000 r--p 00121000 01:00 638 /lib/libc-2.17.so
b6fd1000-b6fd2000 rw-p 00123000 01:00 638 /lib/libc-2.17.so
b6fd2000-b6fd5000 rw-p 00000000 00:00 0 [vectors]
b6fd5000-b6ff4000 r-xp 00000000 01:00 744 /lib/ld-2.17.so
b6ff8000-b6ffa000 rw-p 00000000 00:00 0 [vectors]
b6ffa000-b6ffb000 r-xp 00000000 00:00 0 [vectors]
b6ffb000-b6ffc000 r--p 0001e000 01:00 744 /lib/ld-2.17.so
b6ffc000-b6ffd000 rw-p 0001f000 01:00 744 /lib/ld-2.17.so
be99d000-be9be000 rw-p 00000000 00:00 0 [vectors]
ffff0000-ffff1000 r-xp 00000000 00:00 0 [vectors]

3.10.5:
root@ax3:~# cat /proc/self/maps
00008000-00014000 r-xp 00000000 01:00 258 /bin/cat
0001c000-0001d000 rw-p 0000c000 01:00 258 /bin/cat
0001d000-0003e000 rw-p 00000000 00:00 0 [heap]
b6e6f000-b6f91000 r-xp 00000000 01:00 638 /lib/libc-2.17.so
b6f91000-b6f98000 ---p 00122000 01:00 638 /lib/libc-2.17.so
b6f98000-b6f9a000 r--p 00121000 01:00 638 /lib/libc-2.17.so
b6f9a000-b6f9b000 rw-p 00123000 01:00 638 /lib/libc-2.17.so
b6f9b000-b6f9e000 rw-p 00000000 00:00 0
b6f9e000-b6fbd000 r-xp 00000000 01:00 744 /lib/ld-2.17.so
b6fc2000-b6fc4000 rw-p 00000000 00:00 0
b6fc4000-b6fc5000 r--p 0001e000 01:00 744 /lib/ld-2.17.so
b6fc5000-b6fc6000 rw-p 0001f000 01:00 744 /lib/ld-2.17.so
be9e0000-bea01000 rw-p 00000000 00:00 0 [stack]
ffff0000-ffff1000 r-xp 00000000 00:00 0 [vectors]

Best regards,
Willy

2013-08-09 19:33:32

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [ 000/102] 3.10.6-stable review

On Fri, Aug 09, 2013 at 09:20:30PM +0200, Willy Tarreau wrote:
> Hi Greg,
>
> On Thu, Aug 08, 2013 at 06:56:36PM -0700, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 3.10.6 release.
> > There are 102 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.
>
> Just checked on my OpenBlocks AX3 (dual-core ARMv7 in thumbs mode),
> everything seems OK, I did not even notice any performance regression
> compared to 3.10.5 on syscall intensive workloads with the recent
> changes. I'm sure that I'm using the kuser helpers page since the
> system doesn't boot without. Also I did observe minor changes in
> /proc/self/maps, but I don't think they should have any impact, so
> all in all it's OK :

Wonderful, thanks so much for testing the arm stuff, I wasn't sure I got
it all correct in the backport.

One of these days I'll get a system here that I can test arm changes
on...

thanks,

greg k-h

2013-08-09 19:45:56

by Shuah Khan

[permalink] [raw]
Subject: Re: [ 000/102] 3.10.6-stable review

On 08/09/2013 01:10 PM, Greg Kroah-Hartman wrote:
> On Fri, Aug 09, 2013 at 02:42:24PM +0000, Shuah Khan wrote:
>> On 08/09/2013 07:54 AM, Greg Kroah-Hartman wrote:
>>> This is the start of the stable review cycle for the 3.10.6 release.
>>> There are 102 patches in this series, all will be posted as a response
>>> to this one. If anyone has any issues with these being applied, please
>>> let me know.
>>>
>>> Responses should be made by Sun Aug 11 01:46:31 UTC 2013.
>>> Anything received after that time might be too late.
>>>
>>> The whole patch series can be found in one patch at:
>>> kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.10.6-rc1.gz
>>> and the diffstat can be found below.
>>>
>>> thanks,
>>>
>>> greg k-h
>>>
>>
>> I don't see the new stable release patches on
>>
>> http://www.kernel.org/pub/linux/kernel/v3.0/stable-review/
>>
>> Others were able to download last night as I can see from the test
>> responses. Something must have happened. Tried accessing with ftp client
>> as well.
>
> No, the patches never made it there, I think people were testing based
> on the git tree.
>
> kernel.org is now fixed, and the patches should be there within a few
> minutes.
>
> thanks,
>
> greg k-h
>

Greg,

Noticed the following when I applied 3.10.6-rc1

git apply --index < ../stable_tree_project/patch-3.10.6-rc1
<stdin>:1369: space before tab in indent.
* Revision 13 of all triggering devices id in this quirk have
warning: 1 line adds whitespace errors.

Patch applied fine though.

-- Shuah

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

2013-08-09 19:50:42

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [ 000/102] 3.10.6-stable review

On Fri, Aug 09, 2013 at 07:45:51PM +0000, Shuah Khan wrote:
> On 08/09/2013 01:10 PM, Greg Kroah-Hartman wrote:
> > On Fri, Aug 09, 2013 at 02:42:24PM +0000, Shuah Khan wrote:
> >> On 08/09/2013 07:54 AM, Greg Kroah-Hartman wrote:
> >>> This is the start of the stable review cycle for the 3.10.6 release.
> >>> There are 102 patches in this series, all will be posted as a response
> >>> to this one. If anyone has any issues with these being applied, please
> >>> let me know.
> >>>
> >>> Responses should be made by Sun Aug 11 01:46:31 UTC 2013.
> >>> Anything received after that time might be too late.
> >>>
> >>> The whole patch series can be found in one patch at:
> >>> kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.10.6-rc1.gz
> >>> and the diffstat can be found below.
> >>>
> >>> thanks,
> >>>
> >>> greg k-h
> >>>
> >>
> >> I don't see the new stable release patches on
> >>
> >> http://www.kernel.org/pub/linux/kernel/v3.0/stable-review/
> >>
> >> Others were able to download last night as I can see from the test
> >> responses. Something must have happened. Tried accessing with ftp client
> >> as well.
> >
> > No, the patches never made it there, I think people were testing based
> > on the git tree.
> >
> > kernel.org is now fixed, and the patches should be there within a few
> > minutes.
> >
> > thanks,
> >
> > greg k-h
> >
>
> Greg,
>
> Noticed the following when I applied 3.10.6-rc1
>
> git apply --index < ../stable_tree_project/patch-3.10.6-rc1
> <stdin>:1369: space before tab in indent.
> * Revision 13 of all triggering devices id in this quirk have
> warning: 1 line adds whitespace errors.

Known issue, the original patch causes that same warning, nothing I can
do about it :(

thanks,

greg k-h

2013-08-09 20:01:02

by Willy Tarreau

[permalink] [raw]
Subject: Re: [ 000/102] 3.10.6-stable review

On Fri, Aug 09, 2013 at 12:33:29PM -0700, Greg Kroah-Hartman wrote:
> On Fri, Aug 09, 2013 at 09:20:30PM +0200, Willy Tarreau wrote:
> > Hi Greg,
> >
> > On Thu, Aug 08, 2013 at 06:56:36PM -0700, Greg Kroah-Hartman wrote:
> > > This is the start of the stable review cycle for the 3.10.6 release.
> > > There are 102 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.
> >
> > Just checked on my OpenBlocks AX3 (dual-core ARMv7 in thumbs mode),
> > everything seems OK, I did not even notice any performance regression
> > compared to 3.10.5 on syscall intensive workloads with the recent
> > changes. I'm sure that I'm using the kuser helpers page since the
> > system doesn't boot without. Also I did observe minor changes in
> > /proc/self/maps, but I don't think they should have any impact, so
> > all in all it's OK :
>
> Wonderful, thanks so much for testing the arm stuff, I wasn't sure I got
> it all correct in the backport.

Note that I have not tested in ARM mode nor on older archs. But I don't
think it should change anything from what I've seen in the diffs.

> One of these days I'll get a system here that I can test arm changes
> on...

Just get a Beaglebone Black, it's $45 and Cortex A8 (armv7). Well buy
two, since you'll use the first one for hacking GPIOs to everything :-)

http://beagleboard.org/Products/BeagleBone%20Black

If you want to do cool stuff, the AX3 is by far the best thing I've seen
to date, really, but it's too expensive for a non-profit developer in my
opinion :

https://openblocks.plathome.com/form/obs_verification/input.html

Cheers,
Willy

2013-08-09 20:08:41

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [ 000/102] 3.10.6-stable review

On Fri, Aug 09, 2013 at 10:00:56PM +0200, Willy Tarreau wrote:
> On Fri, Aug 09, 2013 at 12:33:29PM -0700, Greg Kroah-Hartman wrote:
> > On Fri, Aug 09, 2013 at 09:20:30PM +0200, Willy Tarreau wrote:
> > > Hi Greg,
> > >
> > > On Thu, Aug 08, 2013 at 06:56:36PM -0700, Greg Kroah-Hartman wrote:
> > > > This is the start of the stable review cycle for the 3.10.6 release.
> > > > There are 102 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.
> > >
> > > Just checked on my OpenBlocks AX3 (dual-core ARMv7 in thumbs mode),
> > > everything seems OK, I did not even notice any performance regression
> > > compared to 3.10.5 on syscall intensive workloads with the recent
> > > changes. I'm sure that I'm using the kuser helpers page since the
> > > system doesn't boot without. Also I did observe minor changes in
> > > /proc/self/maps, but I don't think they should have any impact, so
> > > all in all it's OK :
> >
> > Wonderful, thanks so much for testing the arm stuff, I wasn't sure I got
> > it all correct in the backport.
>
> Note that I have not tested in ARM mode nor on older archs. But I don't
> think it should change anything from what I've seen in the diffs.
>
> > One of these days I'll get a system here that I can test arm changes
> > on...
>
> Just get a Beaglebone Black, it's $45 and Cortex A8 (armv7). Well buy
> two, since you'll use the first one for hacking GPIOs to everything :-)
>
> http://beagleboard.org/Products/BeagleBone%20Black

I have a pre-production version of this, but I don't think that
everything it needs to work is currently upstream :(

> If you want to do cool stuff, the AX3 is by far the best thing I've seen
> to date, really, but it's too expensive for a non-profit developer in my
> opinion :
>
> https://openblocks.plathome.com/form/obs_verification/input.html

Does it work with a "clean" upstream kernel.org release?

thanks,

greg k-h

2013-08-09 20:28:10

by Willy Tarreau

[permalink] [raw]
Subject: Re: [ 000/102] 3.10.6-stable review

On Fri, Aug 09, 2013 at 01:08:38PM -0700, Greg Kroah-Hartman wrote:
> On Fri, Aug 09, 2013 at 10:00:56PM +0200, Willy Tarreau wrote:
> > Just get a Beaglebone Black, it's $45 and Cortex A8 (armv7). Well buy
> > two, since you'll use the first one for hacking GPIOs to everything :-)
> >
> > http://beagleboard.org/Products/BeagleBone%20Black
>
> I have a pre-production version of this, but I don't think that
> everything it needs to work is currently upstream :(

Ah I never checked indeed. I only got one so it stayed at step 1 (GPIO).

> > If you want to do cool stuff, the AX3 is by far the best thing I've seen
> > to date, really, but it's too expensive for a non-profit developer in my
> > opinion :
> >
> > https://openblocks.plathome.com/form/obs_verification/input.html
>
> Does it work with a "clean" upstream kernel.org release?

Yes, I just booted mine with exactly the mbox patches applied on
top of plain 3.10.5. There's a SATA SSD in it so that you don't even
need to care about the MTD stuff etc... I'm used to boot mine over
the network with a rootfs in the initrd, so everything runs in RAM
because it's more convenient for me, it boots in about 8 seconds.

It started to work since 3.8 and is fine with 3.10+. 3.11 brings
PCIe and some stuff you won't necessarily need for kernel dev.

You won't have the NEON extensions on it (but I doubt you'd need it).

Willy

2013-08-09 23:21:44

by Guenter Roeck

[permalink] [raw]
Subject: Re: [ 000/102] 3.10.6-stable review

On 08/09/2013 12:11 PM, Greg Kroah-Hartman wrote:
> On Thu, Aug 08, 2013 at 11:57:55PM -0700, Guenter Roeck wrote:
>> On 08/08/2013 06:56 PM, Greg Kroah-Hartman wrote:
>>> This is the start of the stable review cycle for the 3.10.6 release.
>>> There are 102 patches in this series, all will be posted as a response
>>> to this one. If anyone has any issues with these being applied, please
>>> let me know.
>>>
>>> Responses should be made by Sun Aug 11 01:46:31 UTC 2013.
>>> Anything received after that time might be too late.
>>>
>>> The whole patch series can be found in one patch at:
>>> kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.10.6-rc1.gz
>>> and the diffstat can be found below.
>>>
>>
>> Cross build results:
>> Total builds: 69 Total build errors: 2
>>
>> Details:
>> http://server.roeck-us.net:8010/builders/stable-queue-3.10/builds/47/steps/shell/logs/stdio/text
>>
>> Same results as before, except that I dropped a couple of builds and added some others.
>
> Thanks for testing.
>
>> The failing builds are arm:allmodconfig and mips:allmodconfig.
>> For both, the errors don't exist in mainline and should be trivial to fix in case anyone is interested.
>>
>> arm:
>> FATAL: modpost: GPL-incompatible module bcm2835-rng.ko uses GPL-only symbol 'platform_driver_unregister'
>>
>> [This one has been fixed upstream with commit 22e8099f4f6621b8d165e238cdef2a1cf655e159. Might be worthwhile
>> adding it to -stable]
>
> Yes, I've now queued it up, thanks.
>

The arm:allmodconfig build still fails, unfortunately. Now it finds different problems.

Turns out you also need
b497ceb964a80ebada3b9b3cea4261409039e25a ([SCSI] nsp32: use mdelay instead of large udelay constants)
930d800bded771b26d9944c47810829130ff7c8c (mtd: omap2: allow bulding as a module)

This time I cherry-picked the commits and did a test build to make sure that it passes.

To fix the MIPS build problem, you'll need
78857614104a26cdada4c53eea104752042bf5a1 (MIPS: Expose missing pci_io{map,unmap} declarations)

I cherry-picked this commit on top of the 3.10 queue and did a test build to make sure that it works.

With those three patches, arm:allmodconfig and mips:allmodconfig build successfully for 3.10.
It would be great if you can add them to the -stable queue for 3.10.

Thanks,
Guenter

2013-08-09 23:29:41

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [ 000/102] 3.10.6-stable review

On Fri, Aug 09, 2013 at 04:21:42PM -0700, Guenter Roeck wrote:
> On 08/09/2013 12:11 PM, Greg Kroah-Hartman wrote:
> >On Thu, Aug 08, 2013 at 11:57:55PM -0700, Guenter Roeck wrote:
> >>On 08/08/2013 06:56 PM, Greg Kroah-Hartman wrote:
> >>>This is the start of the stable review cycle for the 3.10.6 release.
> >>>There are 102 patches in this series, all will be posted as a response
> >>>to this one. If anyone has any issues with these being applied, please
> >>>let me know.
> >>>
> >>>Responses should be made by Sun Aug 11 01:46:31 UTC 2013.
> >>>Anything received after that time might be too late.
> >>>
> >>>The whole patch series can be found in one patch at:
> >>> kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.10.6-rc1.gz
> >>>and the diffstat can be found below.
> >>>
> >>
> >>Cross build results:
> >> Total builds: 69 Total build errors: 2
> >>
> >>Details:
> >> http://server.roeck-us.net:8010/builders/stable-queue-3.10/builds/47/steps/shell/logs/stdio/text
> >>
> >>Same results as before, except that I dropped a couple of builds and added some others.
> >
> >Thanks for testing.
> >
> >>The failing builds are arm:allmodconfig and mips:allmodconfig.
> >>For both, the errors don't exist in mainline and should be trivial to fix in case anyone is interested.
> >>
> >>arm:
> >> FATAL: modpost: GPL-incompatible module bcm2835-rng.ko uses GPL-only symbol 'platform_driver_unregister'
> >>
> >>[This one has been fixed upstream with commit 22e8099f4f6621b8d165e238cdef2a1cf655e159. Might be worthwhile
> >> adding it to -stable]
> >
> >Yes, I've now queued it up, thanks.
> >
>
> The arm:allmodconfig build still fails, unfortunately. Now it finds different problems.
>
> Turns out you also need
> b497ceb964a80ebada3b9b3cea4261409039e25a ([SCSI] nsp32: use mdelay instead of large udelay constants)
> 930d800bded771b26d9944c47810829130ff7c8c (mtd: omap2: allow bulding as a module)
>
> This time I cherry-picked the commits and did a test build to make sure that it passes.
>
> To fix the MIPS build problem, you'll need
> 78857614104a26cdada4c53eea104752042bf5a1 (MIPS: Expose missing pci_io{map,unmap} declarations)
>
> I cherry-picked this commit on top of the 3.10 queue and did a test build to make sure that it works.
>
> With those three patches, arm:allmodconfig and mips:allmodconfig build successfully for 3.10.
> It would be great if you can add them to the -stable queue for 3.10.

Thanks for finding these. I'll queue them up for the next 3.10 release
after this one.

greg k-h

2013-08-10 22:07:14

by Shuah Khan

[permalink] [raw]
Subject: Re: [ 000/102] 3.10.6-stable review

On 08/09/2013 01:10 PM, Greg Kroah-Hartman wrote:
> On Fri, Aug 09, 2013 at 02:42:24PM +0000, Shuah Khan wrote:
>> On 08/09/2013 07:54 AM, Greg Kroah-Hartman wrote:
>>> This is the start of the stable review cycle for the 3.10.6 release.
>>> There are 102 patches in this series, all will be posted as a response
>>> to this one. If anyone has any issues with these being applied, please
>>> let me know.
>>>
>>> Responses should be made by Sun Aug 11 01:46:31 UTC 2013.
>>> Anything received after that time might be too late.
>>>
>>> The whole patch series can be found in one patch at:
>>> kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.10.6-rc1.gz
>>> and the diffstat can be found below.
>>>
>>> thanks,
>>>
>>> greg k-h
>>>
>

Patches applied to 3.0.89, 3.4.56 and 3.10.5

Compiled and booted on the following systems:

Samsung Series 9 900X4C Intel Corei5:
(3.4.57-rc1, 3.10.6-rc1)
HP ProBook 6475b AMD A10-4600M APU with Radeon(tm) HD Graphics:
(3.0.90-rc1, 3.4.57-rc1, and 3.10.6-rc1)

dmesgs for all releases look good. No regressions compared to the
previous dmesgs for each of these releases. dmesg emerg, crit, alert,
err are clean. No regressions in warn.

Cross-compile testing:
HP Compaq dc7700 SFF desktop: x86-64 Intel Core-i2:
(3.0.90-rc1, 3.4.57-rc1, and 3.10.6-rc1)

Cross-compile tests results:

alpha: defconfig passed on all
arm: defconfig passed on all
arm64: not applicable to 3.0.y, 3.4.y. defconfig passed on 3.10.y
blackfin: defconfig passed on all
c6x: not applicable to 3.0.y, defconfig passed on 3.4.y, and 3.10.y
mips: defconfig passed on all
mipsel: defconfig passed on all
powerpc: wii_defconfig passed on all
sh: defconfig passed on all
sparc: defconfig passed on all
tile: tilegx_defconfig passed on all

-- Shuah

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

2013-08-11 03:21:12

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [ 000/102] 3.10.6-stable review

On Sat, Aug 10, 2013 at 10:07:08PM +0000, Shuah Khan wrote:
> On 08/09/2013 01:10 PM, Greg Kroah-Hartman wrote:
> > On Fri, Aug 09, 2013 at 02:42:24PM +0000, Shuah Khan wrote:
> >> On 08/09/2013 07:54 AM, Greg Kroah-Hartman wrote:
> >>> This is the start of the stable review cycle for the 3.10.6 release.
> >>> There are 102 patches in this series, all will be posted as a response
> >>> to this one. If anyone has any issues with these being applied, please
> >>> let me know.
> >>>
> >>> Responses should be made by Sun Aug 11 01:46:31 UTC 2013.
> >>> Anything received after that time might be too late.
> >>>
> >>> The whole patch series can be found in one patch at:
> >>> kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.10.6-rc1.gz
> >>> and the diffstat can be found below.
> >>>
> >>> thanks,
> >>>
> >>> greg k-h
> >>>
> >
>
> Patches applied to 3.0.89, 3.4.56 and 3.10.5
>
> Compiled and booted on the following systems:
>
> Samsung Series 9 900X4C Intel Corei5:
> (3.4.57-rc1, 3.10.6-rc1)
> HP ProBook 6475b AMD A10-4600M APU with Radeon(tm) HD Graphics:
> (3.0.90-rc1, 3.4.57-rc1, and 3.10.6-rc1)
>
> dmesgs for all releases look good. No regressions compared to the
> previous dmesgs for each of these releases. dmesg emerg, crit, alert,
> err are clean. No regressions in warn.

Thanks for testing all of these and letting me know.

greg k-h

2013-08-11 08:09:36

by Vladimir Kondratiev

[permalink] [raw]
Subject: Re: [ 044/102] ath: wil6210: Fix build error

On Thursday, August 08, 2013 06:57:20 PM Greg Kroah-Hartman wrote:
> 3.10-stable review patch. If anyone has any objections, please let me know.

This one is good for stable. I'd suggest to apply also commit
c6c7788fe26fdc91e729f60742815ccdb505fd81 - wil6210: drop -Werror compiler flag
it is not in Linus's tree yet, but in Linville's wireless-next

Thanks, Vladimir

2013-08-11 08:14:12

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [ 044/102] ath: wil6210: Fix build error

On Sun, Aug 11, 2013 at 11:09:24AM +0300, Vladimir Kondratiev wrote:
> On Thursday, August 08, 2013 06:57:20 PM Greg Kroah-Hartman wrote:
> > 3.10-stable review patch. If anyone has any objections, please let me know.
>
> This one is good for stable. I'd suggest to apply also commit
> c6c7788fe26fdc91e729f60742815ccdb505fd81 - wil6210: drop -Werror compiler flag
> it is not in Linus's tree yet, but in Linville's wireless-next

As it's not in Linus's tree yet, please resend this request when it hits
that tree, as there's nothing I can do at the moment with this, and I
know I will not remember it :)

thanks,

greg k-h

2013-08-13 04:02:10

by Guenter Roeck

[permalink] [raw]
Subject: Re: [ 000/102] 3.10.6-stable review

On Fri, Aug 09, 2013 at 12:33:29PM -0700, Greg Kroah-Hartman wrote:
> On Fri, Aug 09, 2013 at 09:20:30PM +0200, Willy Tarreau wrote:
> > Hi Greg,
> >
> > On Thu, Aug 08, 2013 at 06:56:36PM -0700, Greg Kroah-Hartman wrote:
> > > This is the start of the stable review cycle for the 3.10.6 release.
> > > There are 102 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.
> >
> > Just checked on my OpenBlocks AX3 (dual-core ARMv7 in thumbs mode),
> > everything seems OK, I did not even notice any performance regression
> > compared to 3.10.5 on syscall intensive workloads with the recent
> > changes. I'm sure that I'm using the kuser helpers page since the
> > system doesn't boot without. Also I did observe minor changes in
> > /proc/self/maps, but I don't think they should have any impact, so
> > all in all it's OK :
>
> Wonderful, thanks so much for testing the arm stuff, I wasn't sure I got
> it all correct in the backport.
>
> One of these days I'll get a system here that I can test arm changes
> on...
>
Have a look at http://server.roeck-us.net:8010/waterfall.

If everything works as intended, we should get automated builds
for various platforms, plus automated qemu tests for some of them.

I have qemu boot tests running for mips (3.4 and 3.10), ppc (3.0, 3.4, 3.10),
and x86 (3.0, 3.4, 3.10) working. x86_64 and mips64 should follow soon.

Unfortunately, arm tests don't work yet because of a bug in the arm
kernel code.

Builds are started about 30 minutes after a change in the stable-queue
repository has been detected, and complete after 3-4 hours unless
the servers are busy doing real work. Which explains why I can annoy
you with results pretty quickly lately :).

Guenter

2013-08-13 06:40:31

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [ 000/102] 3.10.6-stable review

On Mon, Aug 12, 2013 at 09:02:06PM -0700, Guenter Roeck wrote:
> On Fri, Aug 09, 2013 at 12:33:29PM -0700, Greg Kroah-Hartman wrote:
> > On Fri, Aug 09, 2013 at 09:20:30PM +0200, Willy Tarreau wrote:
> > > Hi Greg,
> > >
> > > On Thu, Aug 08, 2013 at 06:56:36PM -0700, Greg Kroah-Hartman wrote:
> > > > This is the start of the stable review cycle for the 3.10.6 release.
> > > > There are 102 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.
> > >
> > > Just checked on my OpenBlocks AX3 (dual-core ARMv7 in thumbs mode),
> > > everything seems OK, I did not even notice any performance regression
> > > compared to 3.10.5 on syscall intensive workloads with the recent
> > > changes. I'm sure that I'm using the kuser helpers page since the
> > > system doesn't boot without. Also I did observe minor changes in
> > > /proc/self/maps, but I don't think they should have any impact, so
> > > all in all it's OK :
> >
> > Wonderful, thanks so much for testing the arm stuff, I wasn't sure I got
> > it all correct in the backport.
> >
> > One of these days I'll get a system here that I can test arm changes
> > on...
> >
> Have a look at http://server.roeck-us.net:8010/waterfall.
>
> If everything works as intended, we should get automated builds
> for various platforms, plus automated qemu tests for some of them.
>
> I have qemu boot tests running for mips (3.4 and 3.10), ppc (3.0, 3.4, 3.10),
> and x86 (3.0, 3.4, 3.10) working. x86_64 and mips64 should follow soon.
>
> Unfortunately, arm tests don't work yet because of a bug in the arm
> kernel code.
>
> Builds are started about 30 minutes after a change in the stable-queue
> repository has been detected, and complete after 3-4 hours unless
> the servers are busy doing real work. Which explains why I can annoy
> you with results pretty quickly lately :).

Very nice, thanks for doing this, I'll watch it and see what I can break
:)

greg k-h

2014-01-16 15:24:18

by rahulk

[permalink] [raw]
Subject: Re: [ 000/102] 3.10.6-stable review

Hi,
I am working on Xilinx zc702 board with Kernel 3.10.0. Now i want to upgrade
the kernel. While doing these upgradation activity 3.10.4 and 3.10.5 kernel
with xilinx patch sucessfully run on the board. But 3.10.6 kernel with
xilinx patch is not working on the board. Kernel get stuck after console
message "Starting kernel ..." in 3.10.6 kernel. As per my understanding
after these meassage kernel is not getting the entry point of kernel to
Uncompress it. The console messages are given below

zynq-uboot> run sdboot
Copying Linux from SD to RAM...
Device: SDHCI
Manufacturer ID: 87
OEM: 494f
Name: SD
Tran Speed: 50000000
Rd Block Len: 512
SD version 2.0
High Capacity: No
Capacity: 977 MiB
Bus Width: 4-bit
reading uImage

6229968 bytes read
reading devicetree.dtb

10125 bytes read
reading uramdisk.image.gz

4075970 bytes read
## Booting kernel from Legacy Image at 03000000 ...
Image Name: Linux-3.10.6-vestas
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 6229904 Bytes = 5.9 MiB
Load Address: 00008000
Entry Point: 00008000
Verifying Checksum ... OK
## Loading init Ramdisk from Legacy Image at 02000000 ...
Image Name:
Image Type: ARM Linux RAMDisk Image (gzip compressed)
Data Size: 4075906 Bytes = 3.9 MiB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
## Flattened Device Tree blob at 02a00000
Booting using the fdt blob at 0x02a00000
Loading Kernel Image ... OK
OK
Loading Ramdisk to 1fc1c000, end 1ffff182 ... OK
Loading Device Tree to 1fc16000, end 1fc1b78c ... OK

Starting kernel ...











--
View this message in context: http://linux-kernel.2935.n7.nabble.com/000-102-3-10-6-stable-review-tp699811p788341.html
Sent from the Linux Kernel mailing list archive at Nabble.com.