Skip to contentSkip to conversation

3.10.6-stable review

PATCH In review Greg Kroah-Hartman 8 participants 129 messages Aug 9, 2013 – Jan 16, 2014

Subsystems (58)
lore
Share & tools
lore

Greg Kroah-Hartman

author maintainer
#0 lore raw

cover 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(-)
author maintainer
#1 lore raw

PATCH 1/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]>

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

PATCH 2/102 ARM: poison memory between kuser helpers

In reply to Greg Kroah-Hartman

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.

---
 arch/arm/kernel/entry-armv.S |   25 ++++++++++++++++---------
 1 file changed, 16 insertions(+), 9 deletions(-)
arch/arm/kernel/entry-armv.S +16 -9
@@ -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
 
author maintainer
#3 lore raw

PATCH 3/102 ARM: move vector stubs

In reply to Greg Kroah-Hartman

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.

---
 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(-)
arch/arm/Kconfig +2 -1
@@ -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
arch/arm/kernel/entry-armv.S +24 -26

80 lines not on this page · raw message

arch/arm/kernel/traps.c +2 -2
@@ -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);
 }
arch/arm/mm/mmu.c +9 -1
@@ -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.
 	 */
author maintainer
#4 lore raw

PATCH 4/102 ARM: use linker magic for vectors and vector stubs

In reply to Greg Kroah-Hartman

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.

---
 arch/arm/kernel/entry-armv.S  |   28 ++++++++++------------------
 arch/arm/kernel/vmlinux.lds.S |   17 +++++++++++++++++
 2 files changed, 27 insertions(+), 18 deletions(-)
arch/arm/kernel/entry-armv.S +10 -18
@@ -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
 
arch/arm/kernel/vmlinux.lds.S +17 -0
@@ -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 : {
author maintainer
#5 lore raw

PATCH 5/102 ARM: update FIQ support for relocation of vectors

In reply to Greg Kroah-Hartman

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.

---
 arch/arm/kernel/entry-armv.S |    3 +++
 arch/arm/kernel/fiq.c        |   19 ++++++++++++++-----
 2 files changed, 17 insertions(+), 5 deletions(-)
arch/arm/kernel/entry-armv.S +3 -0
@@ -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
arch/arm/kernel/fiq.c +14 -5
@@ -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;
 }
author maintainer
#6 lore raw

PATCH 6/102 ARM: allow kuser helpers to be removed from the vector page

In reply to Greg Kroah-Hartman

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.

---
 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(-)
arch/arm/kernel/entry-armv.S +3 -0
@@ -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	)
 
 /*
arch/arm/kernel/traps.c +14 -9
@@ -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
arch/arm/mm/Kconfig +34 -0
@@ -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
author maintainer
#7 lore raw

PATCH 7/102 ARM: move signal handlers into a vdso-like page

In reply to Greg Kroah-Hartman

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.

---
 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(-)
arch/arm/include/asm/elf.h +4 -0
@@ -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
arch/arm/include/asm/mmu.h +1 -0
@@ -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
arch/arm/kernel/process.c +37 -3
@@ -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
arch/arm/kernel/signal.c +44 -6

87 lines not on this page · raw message

arch/arm/kernel/signal.h deleted +0 -12
@@ -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];
arch/arm/kernel/traps.c +0 -9
@@ -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);
 }
author maintainer
#8 lore raw

PATCH 8/102 ARM: make vectors page inaccessible from userspace

In reply to Greg Kroah-Hartman

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.

---
 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(-)
arch/arm/include/asm/page.h +2 -0
@@ -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>
arch/arm/kernel/process.c +6 -1
@@ -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;
 }
arch/arm/mm/mmu.c +4 -0
@@ -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()) {
#9 lore raw

Re: [ 008/102] ARM: make vectors page inaccessible from userspace

Quoted 6 lines · Greg Kroah-Hartman

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

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

From: Russell King <[email protected]>

Quoted 8 lines

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.

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

author maintainer
#10 lore raw

Re: [ 008/102] ARM: make vectors page inaccessible from userspace

Quoted 17 lines · Stefan Lippers-Hollmann
Quoted 6 lines · Greg Kroah-Hartman

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

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

From: Russell King <[email protected]>

Quoted 8 lines

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.

Quoted 7 lines

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

author maintainer
#11 lore raw

PATCH 9/102 ARM: fix a cockup in 48be69a02 (ARM: move signal handlers into a vdso-like page)

In reply to Greg Kroah-Hartman

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.

---
 arch/arm/kernel/process.c |    9 +++++----
 arch/arm/kernel/signal.c  |   41 +++++++++++++++++++----------------------
 2 files changed, 24 insertions(+), 26 deletions(-)
arch/arm/kernel/process.c +5 -4
@@ -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;
arch/arm/kernel/signal.c +19 -22

54 lines not on this page · raw message

author maintainer
#12 lore raw

PATCH 10/102 ARM: fix nommu builds with 48be69a02 (ARM: move signal handlers into a vdso-like page)

In reply to Greg Kroah-Hartman

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.

---
 arch/arm/include/asm/elf.h |    2 ++
 arch/arm/kernel/signal.c   |    5 ++++-
 2 files changed, 6 insertions(+), 1 deletion(-)
arch/arm/include/asm/elf.h +2 -0
@@ -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
arch/arm/kernel/signal.c +4 -1
@@ -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.
author maintainer
#13 lore raw

PATCH 11/102 powerpc/windfarm: Fix noisy slots-fan on Xserve (rm31)

In reply to Greg Kroah-Hartman

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.

---
 drivers/macintosh/windfarm_rm31.c |   18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)
drivers/macintosh/windfarm_rm31.c +9 -9
@@ -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)
author maintainer
#14 lore raw

PATCH 12/102 ARM: 7784/1: mm: ensure SMP alternates assemble to exactly 4 bytes with Thumb-2

In reply to Greg Kroah-Hartman

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.

---
 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(-)
arch/arm/mm/proc-v7-2level.S +1 -1
@@ -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
arch/arm/mm/proc-v7-3level.S +1 -1
@@ -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
arch/arm/mm/proc-v7.S +6 -5
@@ -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)
author maintainer
#15 lore raw

PATCH 13/102 ARM: 7790/1: Fix deferred mm switch on VIVT processors

In reply to Greg Kroah-Hartman

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.

---
 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(-)
arch/arm/include/asm/mmu.h +2 -0
@@ -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;
arch/arm/include/asm/mmu_context.h +16 -4
@@ -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();
 	}
 }
 
arch/arm/include/asm/thread_info.h +0 -1
@@ -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)
author maintainer
#16 lore raw

PATCH 14/102 ARM: 7791/1: a.out: remove partial a.out support

In reply to Greg Kroah-Hartman

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.

---
 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(-)
arch/arm/Kconfig +0 -1
@@ -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
arch/arm/include/asm/a.out-core.h deleted +0 -45

45 lines not on this page · raw message

arch/arm/include/asm/processor.h +0 -4
@@ -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);					\
 })
 
arch/arm/include/uapi/asm/Kbuild +0 -1
@@ -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
arch/arm/include/uapi/asm/a.out.h deleted +0 -34
@@ -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__ */
author maintainer
#17 lore raw

PATCH 15/102 powerpc: VPHN topology change updates all siblings

In reply to Greg Kroah-Hartman

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

---
 arch/powerpc/include/asm/smp.h |    4 ++
 arch/powerpc/mm/numa.c         |   59 ++++++++++++++++++++++++++++++-----------
 2 files changed, 48 insertions(+), 15 deletions(-)
arch/powerpc/include/asm/smp.h +4 -0
@@ -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 */
 
arch/powerpc/mm/numa.c +44 -15

95 lines not on this page · raw message

author maintainer
#18 lore raw

PATCH 16/102 parisc: agp/parisc-agp: allow binding of user memory to the AGP GART

In reply to Greg Kroah-Hartman

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

---
 drivers/char/agp/parisc-agp.c |    6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)
drivers/char/agp/parisc-agp.c +4 -2
@@ -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;
 	}
 
author maintainer
#19 lore raw

PATCH 17/102 parisc: Fix cache routines to ignore vmas with an invalid pfn

In reply to Greg Kroah-Hartman

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.

---
 arch/parisc/kernel/cache.c |  133 +++++++++++++++++++++++----------------------
 1 file changed, 70 insertions(+), 63 deletions(-)
arch/parisc/kernel/cache.c +70 -63
@@ -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
author maintainer
#20 lore raw

PATCH 18/102 parisc: Fix interrupt routing for C8000 serial ports

In reply to Greg Kroah-Hartman

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.

---
 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(-)
arch/parisc/include/asm/parisc-device.h +3 -0
@@ -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_*/
arch/parisc/kernel/inventory.c +1 -0
@@ -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 */
 
drivers/parisc/iosapic.c +27 -11
@@ -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;
 }
 
drivers/tty/serial/8250/8250_gsc.c +1 -2
@@ -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) {
author maintainer
#21 lore raw

PATCH 19/102 hwmon: (max6697) fix MAX6581 ideality

In reply to Greg Kroah-Hartman

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.

---
 drivers/hwmon/max6697.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/hwmon/max6697.c +2 -2
@@ -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;
 	}
author maintainer
#22 lore raw

PATCH 20/102 ALSA: hda - Fix missing fixup for Mac Mini with STAC9221

In reply to Greg Kroah-Hartman

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

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

From: Takashi Iwai <[email protected]>

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

---
 sound/pci/hda/hda_auto_parser.c |    2 +-
 sound/pci/hda/patch_sigmatel.c  |    1 +
 2 files changed, 2 insertions(+), 1 deletion(-)
sound/pci/hda/hda_auto_parser.c +1 -1
@@ -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;
sound/pci/hda/patch_sigmatel.c +1 -0
@@ -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),
author maintainer
#23 lore raw

PATCH 21/102 ALSA: compress: fix the return value for SNDRV_COMPRESS_VERSION

In reply to Greg Kroah-Hartman

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

---
 sound/core/compress_offload.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
sound/core/compress_offload.c +1 -1
@@ -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):
author maintainer
#24 lore raw

PATCH 22/102 serial/mxs-auart: fix race condition in interrupt handler

In reply to Greg Kroah-Hartman

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.

---
 drivers/tty/serial/mxs-auart.c |   17 +++++++++--------
 1 file changed, 9 insertions(+), 8 deletions(-)
drivers/tty/serial/mxs-auart.c +9 -8
@@ -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;
 }
 
author maintainer
#25 lore raw

PATCH 23/102 serial: arc_uart: Fix module alias

In reply to Greg Kroah-Hartman

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.

---
 drivers/tty/serial/arc_uart.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/tty/serial/arc_uart.c +1 -1
@@ -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");
author maintainer
#26 lore raw

PATCH 24/102 serial/mxs-auart: increase time to wait for transmitter to become idle

In reply to Greg Kroah-Hartman

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.

---
 drivers/tty/serial/mxs-auart.c |   21 +++++++++++++--------
 1 file changed, 13 insertions(+), 8 deletions(-)
drivers/tty/serial/mxs-auart.c +13 -8
@@ -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);
 }
author maintainer
#27 lore raw

PATCH 25/102 dma: pl330: Fix cyclic transfers

In reply to Greg Kroah-Hartman

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.

---
 drivers/dma/pl330.c |   93 +++++++++++++++++++++++++++++++++++++---------------
 1 file changed, 67 insertions(+), 26 deletions(-)
drivers/dma/pl330.c +67 -26
@@ -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;
 }
author maintainer
#28 lore raw

PATCH 26/102 USB: mos7840: fix race in register handling

In reply to Greg Kroah-Hartman

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.

---
 drivers/usb/serial/mos7840.c |   18 ++++++++++++++++--
 1 file changed, 16 insertions(+), 2 deletions(-)
drivers/usb/serial/mos7840.c +16 -2
@@ -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;
 }
 
author maintainer
#29 lore raw

PATCH 27/102 USB: mos7840: fix device-type detection

In reply to Greg Kroah-Hartman

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.

---
 drivers/usb/serial/mos7840.c |   75 ++++++++++++++++++++-----------------------
 1 file changed, 35 insertions(+), 40 deletions(-)
drivers/usb/serial/mos7840.c +35 -40
@@ -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,
author maintainer
#30 lore raw

PATCH 28/102 USB: mos7840: fix race in led handling

In reply to Greg Kroah-Hartman

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.

---
 drivers/usb/serial/mos7840.c |   59 ++++++++++++++++++++++++++-----------------
 1 file changed, 37 insertions(+), 22 deletions(-)
drivers/usb/serial/mos7840.c +37 -22
@@ -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);
author maintainer
#31 lore raw

PATCH 29/102 USB: mos7840: fix pointer casts

In reply to Greg Kroah-Hartman

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]

---
 drivers/usb/serial/mos7840.c |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)
drivers/usb/serial/mos7840.c +3 -3
@@ -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;
author maintainer
#32 lore raw

PATCH 30/102 iwlwifi: mvm: fix L2P BA ressources leak

In reply to Greg Kroah-Hartman

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.

---
 drivers/net/wireless/iwlwifi/mvm/sta.c |    8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)
drivers/net/wireless/iwlwifi/mvm/sta.c +6 -2
@@ -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;
 
author maintainer
#33 lore raw

PATCH 31/102 iwlwifi: mvm: fix bug in scan ssid

In reply to Greg Kroah-Hartman

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.

---
 drivers/net/wireless/iwlwifi/mvm/scan.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/net/wireless/iwlwifi/mvm/scan.c +2 -2
@@ -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,
author maintainer
#34 lore raw

PATCH 32/102 iwlwifi: mvm: refuse connection to APs with BI < 16

In reply to Greg Kroah-Hartman

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

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

From: Johannes Berg <[email protected]>

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

---
 drivers/net/wireless/iwlwifi/mvm/mac80211.c |   16 ++++++++++++++++
 1 file changed, 16 insertions(+)
drivers/net/wireless/iwlwifi/mvm/mac80211.c +16 -0
@@ -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;
author maintainer
#35 lore raw

PATCH 33/102 iwlwifi: add DELL SKU for 5150 HMC

In reply to Greg Kroah-Hartman

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

---
 drivers/net/wireless/iwlwifi/pcie/drv.c |    1 +
 1 file changed, 1 insertion(+)
drivers/net/wireless/iwlwifi/pcie/drv.c +1 -0
@@ -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 */
author maintainer
#36 lore raw

PATCH 34/102 iwlwifi: mvm: fix flushing not started aggregation sessions

In reply to Greg Kroah-Hartman

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

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

From: Johannes Berg <[email protected]>

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

---
 drivers/net/wireless/iwlwifi/mvm/sta.c |   11 ++++++++---
 1 file changed, 8 insertions(+), 3 deletions(-)
drivers/net/wireless/iwlwifi/mvm/sta.c +8 -3
@@ -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;
 
author maintainer
#37 lore raw

PATCH 35/102 ath9k_htc: do some initial hardware configuration

In reply to Greg Kroah-Hartman

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.

---
 drivers/net/wireless/ath/ath9k/htc_drv_init.c |    1 +
 1 file changed, 1 insertion(+)
drivers/net/wireless/ath/ath9k/htc_drv_init.c +1 -0
@@ -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,
author maintainer
#38 lore raw

PATCH 36/102 ath9k_htc: reboot firmware if it was loaded

In reply to Greg Kroah-Hartman

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

---
 drivers/net/wireless/ath/ath9k/hif_usb.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/net/wireless/ath/ath9k/hif_usb.c +3 -1
@@ -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);
author maintainer
#39 lore raw

PATCH 37/102 nl80211: fix mgmt tx status and testmode reporting for netns

In reply to Greg Kroah-Hartman

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.

---
 net/wireless/nl80211.c |    7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)
net/wireless/nl80211.c +5 -2
@@ -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:
author maintainer
#40 lore raw

PATCH 38/102 mac80211/minstrel: fix NULL pointer dereference issue

In reply to Greg Kroah-Hartman

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

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

From: Felix Fietkau <[email protected]>

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

---
 net/mac80211/rc80211_minstrel.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
net/mac80211/rc80211_minstrel.c +2 -1
@@ -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;
author maintainer
#41 lore raw

PATCH 39/102 mac80211/minstrel_ht: fix cck rate sampling

In reply to Greg Kroah-Hartman

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

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

From: Felix Fietkau <[email protected]>

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

---
 net/mac80211/rc80211_minstrel_ht.c |   10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)
net/mac80211/rc80211_minstrel_ht.c +9 -1
@@ -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
author maintainer
#42 lore raw

PATCH 40/102 mac80211: fix duplicate retransmission detection

In reply to Greg Kroah-Hartman

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

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

From: Johannes Berg <[email protected]>

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

---
 net/mac80211/rx.c |   10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)
net/mac80211/rx.c +8 -2
@@ -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)) {
author maintainer
#43 lore raw

PATCH 41/102 mac80211: fix ethtool stats for non-station interfaces

In reply to Greg Kroah-Hartman

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

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

From: Johannes Berg <[email protected]>

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

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

PATCH 42/102 mac80211: fix monitor interface suspend crash regression

In reply to Greg Kroah-Hartman

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

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

From: Stanislaw Gruszka <[email protected]>

commit 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

---
 net/mac80211/pm.c |    7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)
net/mac80211/pm.c +5 -2
@@ -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);
 	}
 
author maintainer
#45 lore raw

PATCH 43/102 ixgbe: Fix Tx Hang issue with lldpad on 82598EB

In reply to Greg Kroah-Hartman

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.

---
 drivers/net/ethernet/intel/ixgbe/ixgbe_dcb_82598.c |    3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)
drivers/net/ethernet/intel/ixgbe/ixgbe_dcb_82598.c +1 -2
@@ -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);
 
author maintainer
#46 lore raw

PATCH 44/102 ath: wil6210: Fix build error

In reply to Greg Kroah-Hartman

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

---
 drivers/net/wireless/ath/wil6210/debugfs.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/net/wireless/ath/wil6210/debugfs.c +2 -2
@@ -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;
#47 lore raw

Re: [ 044/102] ath: wil6210: Fix build error

Quoted 1 line · Greg Kroah-Hartman

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

author maintainer
#48 lore raw

Re: [ 044/102] ath: wil6210: Fix build error

Quoted 6 lines · Vladimir Kondratiev
Quoted 1 line · Greg Kroah-Hartman

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

author maintainer
#49 lore raw

PATCH 45/102 Bluetooth: Fix invalid length check in l2cap_information_rsp()

In reply to Greg Kroah-Hartman

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.

Quoted 1 line

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

---
 net/bluetooth/l2cap_core.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
net/bluetooth/l2cap_core.c +1 -1
@@ -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);
#50 lore raw

Re: [ 045/102] Bluetooth: Fix invalid length check in l2cap_information_rsp()

Hi Greg,

Quoted 39 lines · Greg Kroah-Hartman

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.

Quoted 1 line

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

---
 net/bluetooth/l2cap_core.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

net/bluetooth/l2cap_core.c static inline int l2cap_disconnect_rsp(s · line 4246

Quoted 8 lines
net/bluetooth/l2cap_core.c +1 -1
@@ -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

author maintainer
#51 lore raw

Re: [ 045/102] Bluetooth: Fix invalid length check in l2cap_information_rsp()

Quoted 56 lines · Johan Hedberg

Hi Greg,

Quoted 39 lines · Greg Kroah-Hartman

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.

Quoted 1 line

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

---
 net/bluetooth/l2cap_core.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

net/bluetooth/l2cap_core.c static inline int l2cap_disconnect_rsp(s · line 4246

Quoted 8 lines
net/bluetooth/l2cap_core.c +1 -1
@@ -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).

Quoted 4 lines

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

author maintainer
#52 lore raw

PATCH 46/102 Bluetooth: ath3k: Add support for Fujitsu Lifebook UH5x2 [04c5:1330]

In reply to Greg Kroah-Hartman

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
---
 drivers/bluetooth/ath3k.c |    2 ++
 drivers/bluetooth/btusb.c |    1 +
 2 files changed, 3 insertions(+)
drivers/bluetooth/ath3k.c +2 -0
@@ -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 },
drivers/bluetooth/btusb.c +1 -0
@@ -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 },
author maintainer
#53 lore raw

PATCH 47/102 Bluetooth: ath3k: dont use stack memory for DMA

In reply to Greg Kroah-Hartman

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

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

From: Stanislaw Gruszka <[email protected]>

commit 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

---
 drivers/bluetooth/ath3k.c |   38 +++++++++++++++++++++++++++++---------
 1 file changed, 29 insertions(+), 9 deletions(-)
drivers/bluetooth/ath3k.c +29 -9
@@ -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,
author maintainer
#54 lore raw

PATCH 48/102 Bluetooth: ath3k: Add support for ID 0x13d3/0x3402

In reply to Greg Kroah-Hartman

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

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

From: Sujith Manoharan <[email protected]>

commit 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

---
 drivers/bluetooth/ath3k.c |    2 ++
 drivers/bluetooth/btusb.c |    1 +
 2 files changed, 3 insertions(+)
drivers/bluetooth/ath3k.c +2 -0
@@ -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 },
drivers/bluetooth/btusb.c +1 -0
@@ -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 },
author maintainer
#55 lore raw

PATCH 49/102 Bluetooth: Add support for Atheros [0cf3:3121]

In reply to Greg Kroah-Hartman

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
---
 drivers/bluetooth/ath3k.c |    2 ++
 drivers/bluetooth/btusb.c |    1 +
 2 files changed, 3 insertions(+)
drivers/bluetooth/ath3k.c +2 -0
@@ -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 },
drivers/bluetooth/btusb.c +1 -0
@@ -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 },
author maintainer
#56 lore raw

PATCH 50/102 Bluetooth: Add support for Atheros [0cf3:e003]

In reply to Greg Kroah-Hartman

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
---
 drivers/bluetooth/ath3k.c |    2 ++
 drivers/bluetooth/btusb.c |    1 +
 2 files changed, 3 insertions(+)
drivers/bluetooth/ath3k.c +2 -0
@@ -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 },
drivers/bluetooth/btusb.c +1 -0
@@ -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 },
author maintainer
#57 lore raw

PATCH 51/102 Bluetooth: Add support for Mediatek Bluetooth device [0e8d:763f]

In reply to Greg Kroah-Hartman

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
---
 drivers/bluetooth/btusb.c |    3 +++
 1 file changed, 3 insertions(+)
drivers/bluetooth/btusb.c +3 -0
@@ -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) },
 
author maintainer
#58 lore raw

PATCH 52/102 Bluetooth: fix wrong use of PTR_ERR() in btusb

In reply to Greg Kroah-Hartman

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]
---
 drivers/bluetooth/btusb.c |   14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)
drivers/bluetooth/btusb.c +7 -7
@@ -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);
 
author maintainer
#59 lore raw

PATCH 53/102 svcrpc: fix gss-proxy xdr decoding oops

In reply to Greg Kroah-Hartman

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.

---
 net/sunrpc/auth_gss/gss_rpc_xdr.c |    9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)
net/sunrpc/auth_gss/gss_rpc_xdr.c +5 -4
@@ -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 */
author maintainer
#60 lore raw

PATCH 54/102 svcrpc: fix gss_rpc_upcall create error

In reply to Greg Kroah-Hartman

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

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

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

commit 9f96392b0ae6aefc02a9b900c3f4889dfafc8402 upstream.

---
 net/sunrpc/auth_gss/gss_rpc_upcall.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
net/sunrpc/auth_gss/gss_rpc_upcall.c +1 -1
@@ -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;
 	}
author maintainer
#61 lore raw

PATCH 55/102 svcrpc: fix kfree oops in gss-proxy code

In reply to Greg Kroah-Hartman

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.

---
 net/sunrpc/auth_gss/gss_rpc_upcall.c |    1 -
 1 file changed, 1 deletion(-)
net/sunrpc/auth_gss/gss_rpc_upcall.c +0 -1
@@ -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);
 }
 
author maintainer
#62 lore raw

PATCH 56/102 rt2x00: fix stop queue

In reply to Greg Kroah-Hartman

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

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

From: Stanislaw Gruszka <[email protected]>

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

---
 drivers/net/wireless/rt2x00/rt2x00queue.c |   18 +++++++++++-------
 1 file changed, 11 insertions(+), 7 deletions(-)
drivers/net/wireless/rt2x00/rt2x00queue.c +11 -7
@@ -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);
 
author maintainer
#63 lore raw

PATCH 57/102 mwifiex: Add missing endian conversion.

In reply to Greg Kroah-Hartman

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.

---
 drivers/net/wireless/mwifiex/sdio.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/net/wireless/mwifiex/sdio.c +2 -2
@@ -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
author maintainer
#64 lore raw

PATCH 58/102 mwifiex: check for bss_role instead of bss_mode for STA operations

In reply to Greg Kroah-Hartman

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.

---
 drivers/net/wireless/mwifiex/cfg80211.c |    4 ++--
 drivers/net/wireless/mwifiex/join.c     |    6 ++++--
 2 files changed, 6 insertions(+), 4 deletions(-)
drivers/net/wireless/mwifiex/cfg80211.c +2 -2
@@ -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;
 	}
drivers/net/wireless/mwifiex/join.c +4 -2
@@ -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;
 
author maintainer
#65 lore raw

PATCH 59/102 mwifiex: fix wrong data rates in P2P client

In reply to Greg Kroah-Hartman

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.

---
 drivers/net/wireless/mwifiex/cfp.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/net/wireless/mwifiex/cfp.c +2 -1
@@ -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 "
author maintainer
#66 lore raw

PATCH 60/102 zram: avoid invalid memory access in zram_exit()

In reply to Greg Kroah-Hartman

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

---
 drivers/staging/zram/zram_drv.c |    2 ++
 1 file changed, 2 insertions(+)
drivers/staging/zram/zram_drv.c +2 -0
@@ -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");
author maintainer
#67 lore raw

PATCH 61/102 zram: use zram->lock to protect zram_free_page() in swap free notify path

In reply to Greg Kroah-Hartman

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

---
 drivers/staging/zram/zram_drv.c |    2 ++
 drivers/staging/zram/zram_drv.h |    5 +++--
 2 files changed, 5 insertions(+), 2 deletions(-)
drivers/staging/zram/zram_drv.c +2 -0
@@ -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);
 }
 
drivers/staging/zram/zram_drv.h +3 -2
@@ -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;
author maintainer
#68 lore raw

PATCH 62/102 zram: destroy all devices on error recovery path in zram_init()

In reply to Greg Kroah-Hartman

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.

---
 drivers/staging/zram/zram_drv.c |   15 +++++++++------
 1 file changed, 9 insertions(+), 6 deletions(-)
drivers/staging/zram/zram_drv.c +9 -6
@@ -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;
 }
author maintainer
#69 lore raw

PATCH 63/102 zram: avoid double free in function zram_bvec_write()

In reply to Greg Kroah-Hartman

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.

---
 drivers/staging/zram/zram_drv.c |    2 --
 1 file changed, 2 deletions(-)
drivers/staging/zram/zram_drv.c +0 -2
@@ -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;
author maintainer
#70 lore raw

PATCH 64/102 zram: avoid access beyond the zram device

In reply to Greg Kroah-Hartman

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.

---
 drivers/staging/zram/zram_drv.c |   17 ++++++++++++-----
 1 file changed, 12 insertions(+), 5 deletions(-)
drivers/staging/zram/zram_drv.c +12 -5
@@ -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;
author maintainer
#71 lore raw

PATCH 65/102 zram: protect sysfs handler from invalid memory access

In reply to Greg Kroah-Hartman

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

---
 drivers/staging/zram/zram_sysfs.c |    2 ++
 1 file changed, 2 insertions(+)
drivers/staging/zram/zram_sysfs.c +2 -0
@@ -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);
 }
author maintainer
#72 lore raw

PATCH 66/102 ACPI / battery: Fix parsing _BIX return value

In reply to Greg Kroah-Hartman

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

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

From: Lan Tianyu <[email protected]>

commit 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

---
 drivers/acpi/battery.c |    2 ++
 1 file changed, 2 insertions(+)
drivers/acpi/battery.c +2 -0
@@ -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},
author maintainer
#73 lore raw

PATCH 67/102 Revert "cpuidle: Quickly notice prediction failure in general case"

In reply to Greg Kroah-Hartman

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.

---
 drivers/cpuidle/governors/menu.c |   35 +----------------------------------
 1 file changed, 1 insertion(+), 34 deletions(-)
drivers/cpuidle/governors/menu.c +1 -34
@@ -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;
author maintainer
#74 lore raw

PATCH 68/102 cpufreq: Fix cpufreq driver module refcount balance after suspend/resume

In reply to Greg Kroah-Hartman

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.

---
 drivers/cpufreq/cpufreq.c |   19 ++++++++++---------
 1 file changed, 10 insertions(+), 9 deletions(-)
drivers/cpufreq/cpufreq.c +10 -9
@@ -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;
author maintainer
#75 lore raw

PATCH 69/102 Revert "cpuidle: Quickly notice prediction failure for repeat mode"

In reply to Greg Kroah-Hartman

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.

---
 drivers/cpuidle/governors/menu.c |   73 ++-------------------------------------
 include/linux/tick.h             |    6 ---
 kernel/time/tick-sched.c         |    9 +---
 3 files changed, 6 insertions(+), 82 deletions(-)
drivers/cpuidle/governors/menu.c +4 -69
@@ -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));
 
include/linux/tick.h +0 -6
@@ -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
kernel/time/tick-sched.c +2 -7
@@ -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();
 
author maintainer
#76 lore raw

PATCH 70/102 PCI: pciehp: Fix null pointer deref when hot-removing SR-IOV device

In reply to Greg Kroah-Hartman

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

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

From: Yinghai Lu <[email protected]>

commit 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

---
 drivers/pci/hotplug/pciehp_pci.c |    9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)
drivers/pci/hotplug/pciehp_pci.c +8 -1
@@ -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);
author maintainer
#77 lore raw

PATCH 71/102 PCI: Retry allocation of only the resource type that failed

In reply to Greg Kroah-Hartman

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

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

From: Yinghai Lu <[email protected]>

commit 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

---
 drivers/pci/setup-bus.c |   69 +++++++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 68 insertions(+), 1 deletion(-)
drivers/pci/setup-bus.c +68 -1
@@ -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)
author maintainer
#78 lore raw

PATCH 72/102 drm/radeon: Disable dma rings for bo moves on r6xx

In reply to Greg Kroah-Hartman

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.

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

PATCH 73/102 xen-blkfront: use a different scatterlist for each request

In reply to Greg Kroah-Hartman

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

---
 drivers/block/xen-blkfront.c |   36 +++++++++++++++++-------------------
 1 file changed, 17 insertions(+), 19 deletions(-)
drivers/block/xen-blkfront.c +17 -19
@@ -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 *
author maintainer
#80 lore raw

PATCH 74/102 drm/i915: Preserve the DDI_A_4_LANES bit from the bios

In reply to Greg Kroah-Hartman

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.

---
 drivers/gpu/drm/i915/intel_ddi.c |   10 ++++++----
 drivers/gpu/drm/i915/intel_drv.h |    2 +-
 2 files changed, 7 insertions(+), 5 deletions(-)
drivers/gpu/drm/i915/intel_ddi.c +6 -4
@@ -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);
drivers/gpu/drm/i915/intel_drv.h +1 -1
@@ -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;
 };
author maintainer
#81 lore raw

PATCH 75/102 fanotify: info leak in copy_event_to_user()

In reply to Greg Kroah-Hartman

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.

---
 fs/notify/fanotify/fanotify_user.c |    1 +
 1 file changed, 1 insertion(+)
fs/notify/fanotify/fanotify_user.c +1 -0
@@ -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))
author maintainer
#82 lore raw

PATCH 76/102 cgroup: fix umount vs cgroup_cfts_commit() race

In reply to Greg Kroah-Hartman

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]
---
 kernel/cgroup.c |    9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)
kernel/cgroup.c +8 -1
@@ -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);
 }
 
author maintainer
#83 lore raw

PATCH 77/102 drm/radeon: never unpin UVD bo v3

In reply to Greg Kroah-Hartman

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.

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.

---
 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(-)
drivers/gpu/drm/radeon/radeon.h +2 -1
@@ -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 */
drivers/gpu/drm/radeon/radeon_fence.c +1 -1
@@ -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;
 		}
drivers/gpu/drm/radeon/radeon_uvd.c +48 -52

155 lines not on this page · raw message

drivers/gpu/drm/radeon/rv770.c +1 -1
@@ -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);
 
author maintainer
#84 lore raw

PATCH 78/102 x86, fpu: correct the asm constraints for fxsave, unbreak mxcsr.daz

In reply to Greg Kroah-Hartman

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.

---
 arch/x86/kernel/i387.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
arch/x86/kernel/i387.c +1 -1
@@ -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;
author maintainer
#85 lore raw

PATCH 79/102 Btrfs: fix crash regarding to ulist_add_merge

In reply to Greg Kroah-Hartman

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.

---
 fs/btrfs/ulist.c |   15 +++++++++++++++
 1 file changed, 15 insertions(+)
fs/btrfs/ulist.c +15 -0
@@ -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;
author maintainer
#86 lore raw

PATCH 80/102 drm/i915: make SDVO TV-out work for multifunction devices

In reply to Greg Kroah-Hartman

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

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

---
 drivers/gpu/drm/i915/intel_display.c |    8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)
drivers/gpu/drm/i915/intel_display.c +5 -3
@@ -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;
author maintainer
#87 lore raw

PATCH 81/102 s390: add support for IBM zBC12 machine

In reply to Greg Kroah-Hartman

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.

---
 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(-)
arch/s390/Kconfig +4 -3
@@ -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
 
arch/s390/kernel/setup.c +1 -0
@@ -998,6 +998,7 @@ static void __init setup_hwcaps(void)
 		strcpy(elf_platform, "z196");
 		break;
 	case 0x2827:
+	case 0x2828:
 		strcpy(elf_platform, "zEC12");
 		break;
 	}
arch/s390/mm/init.c +1 -0
@@ -69,6 +69,7 @@ static void __init setup_zero_pages(void
 		order = 2;
 		break;
 	case 0x2827:	/* zEC12 */
+	case 0x2828:	/* zEC12 */
 	default:
 		order = 5;
 		break;
arch/s390/oprofile/init.c +1 -1
@@ -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;
 		}
 	}
author maintainer
#88 lore raw

PATCH 82/102 s390/bitops: fix find_next_bit_left

In reply to Greg Kroah-Hartman

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.

---
 arch/s390/include/asm/bitops.h |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
arch/s390/include/asm/bitops.h +1 -1
@@ -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)
author maintainer
#89 lore raw

PATCH 83/102 workqueue: copy workqueue_attrs with all fields

In reply to Greg Kroah-Hartman

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.

---
 kernel/workqueue.c |   12 ++++++++++++
 1 file changed, 12 insertions(+)
kernel/workqueue.c +12 -0
@@ -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) {
author maintainer
#90 lore raw

PATCH 84/102 userns: unshare_userns(&cred) should not populate cred on failure

In reply to Greg Kroah-Hartman

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.

---
 kernel/user_namespace.c |   13 +++++++++----
 1 file changed, 9 insertions(+), 4 deletions(-)
kernel/user_namespace.c +9 -4
@@ -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)
author maintainer
#91 lore raw

PATCH 85/102 x86/iommu/vt-d: Expand interrupt remapping quirk to cover x58 chipset

In reply to Greg Kroah-Hartman

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:

---
 arch/x86/kernel/early-quirks.c |   14 ++++++++++++--
 1 file changed, 12 insertions(+), 2 deletions(-)
arch/x86/kernel/early-quirks.c +12 -2
@@ -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 },
 	{}
author maintainer
#92 lore raw

PATCH 86/102 spi: spi-davinci: Fix direction in dma_map_single()

In reply to Greg Kroah-Hartman

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.

---
 drivers/spi/spi-davinci.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/spi/spi-davinci.c +1 -1
@@ -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;
author maintainer
#93 lore raw

PATCH 87/102 arcnet: cleanup sizeof parameter

In reply to Greg Kroah-Hartman

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.

---
 drivers/net/arcnet/arcnet.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/arcnet/arcnet.c +1 -1
@@ -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;
author maintainer
#94 lore raw

PATCH 88/102 sysctl net: Keep tcp_syn_retries inside the boundary

In reply to Greg Kroah-Hartman

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.

---
 net/ipv4/sysctl_net_ipv4.c |    6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)
net/ipv4/sysctl_net_ipv4.c +5 -1
@@ -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",
author maintainer
#95 lore raw

PATCH 89/102 sfc: Enable RX scatter for flows steered by RFS

In reply to Greg Kroah-Hartman

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.

---
 drivers/net/ethernet/sfc/filter.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/net/ethernet/sfc/filter.c +3 -1
@@ -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)
author maintainer
#96 lore raw

PATCH 90/102 ipv6: take rtnl_lock and mark mrt6 table as freed on namespace cleanup

In reply to Greg Kroah-Hartman

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

---
 net/ipv6/ip6mr.c |    5 +++++
 1 file changed, 5 insertions(+)
net/ipv6/ip6mr.c +5 -0
@@ -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
 
author maintainer
#97 lore raw

PATCH 91/102 usbnet: do not pretend to support SG/TSO

In reply to Greg Kroah-Hartman

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

---
 drivers/net/usb/ax88179_178a.c |    9 ++++-----
 drivers/net/usb/smsc75xx.c     |   12 +++---------
 2 files changed, 7 insertions(+), 14 deletions(-)
drivers/net/usb/ax88179_178a.c +4 -5
@@ -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 |
drivers/net/usb/smsc75xx.c +3 -9
@@ -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);
author maintainer
#98 lore raw

PATCH 92/102 genetlink: release cb_lock before requesting additional module

In reply to Greg Kroah-Hartman

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

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

From: Stanislaw Gruszka <[email protected]>

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

PATCH 93/102 net_sched: Fix stack info leak in cbq_dump_wrr().

In reply to Greg Kroah-Hartman

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.

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

PATCH 94/102 af_key: more info leaks in pfkey messages

In reply to Greg Kroah-Hartman

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.

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

PATCH 95/102 atl1c: use custom skb allocator

In reply to Greg Kroah-Hartman

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.

---
 drivers/net/ethernet/atheros/atl1c/atl1c.h      |    3 +
 drivers/net/ethernet/atheros/atl1c/atl1c_main.c |   40 +++++++++++++++++++++++-
 2 files changed, 42 insertions(+), 1 deletion(-)
drivers/net/ethernet/atheros/atl1c/atl1c.h +3 -0
@@ -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 */
drivers/net/ethernet/atheros/atl1c/atl1c_main.c +39 -1
@@ -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");
author maintainer
#102 lore raw

PATCH 96/102 net_sched: info leak in atm_tc_dump_class()

In reply to Greg Kroah-Hartman

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.

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

PATCH 97/102 ndisc: Add missing inline to ndisc_addr_option_pad

In reply to Greg Kroah-Hartman

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

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

From: Joe Perches <[email protected]>

[ Upstream commit d9d10a30964504af834d8d250a0c76d4ae91eb1e ]

---
 include/net/ndisc.h |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
include/net/ndisc.h +1 -1
@@ -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;
author maintainer
#104 lore raw

PATCH 98/102 8139cp: Add dma_mapping_error checking

In reply to Greg Kroah-Hartman

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.

---
 drivers/net/ethernet/realtek/8139cp.c |   48 +++++++++++++++++++++++++++++++---
 1 file changed, 45 insertions(+), 3 deletions(-)
drivers/net/ethernet/realtek/8139cp.c +45 -3
@@ -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;
author maintainer
#105 lore raw

PATCH 99/102 net/mlx4_core: Dont give VFs MAC addresses which are derived from the PF MAC

In reply to Greg Kroah-Hartman

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.

---
 drivers/net/ethernet/mellanox/mlx4/fw.c |   11 +----------
 1 file changed, 1 insertion(+), 10 deletions(-)
drivers/net/ethernet/mellanox/mlx4/fw.c +1 -10
@@ -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 */
author maintainer
#106 lore raw

PATCH 100/102 net/mlx4_core: VFs must ignore the enable_64b_cqe_eqe module param

In reply to Greg Kroah-Hartman

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

---
 drivers/net/ethernet/mellanox/mlx4/main.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/ethernet/mellanox/mlx4/main.c +1 -1
@@ -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");
author maintainer
#107 lore raw

PATCH 101/102 iwlwifi: mvm: set SSID bits for passive channels

In reply to Greg Kroah-Hartman

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.

---
 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(-)
drivers/net/wireless/iwlwifi/mvm/fw-api-scan.h +0 -1
@@ -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)
 
drivers/net/wireless/iwlwifi/mvm/scan.c +2 -9
@@ -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);
author maintainer
#108 lore raw

PATCH 102/102 iwlwifi: dvm: dont send BT_CONFIG on devices w/o Bluetooth

In reply to Greg Kroah-Hartman

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

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

From: Johannes Berg <[email protected]>

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

---
 drivers/net/wireless/iwlwifi/dvm/main.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/wireless/iwlwifi/dvm/main.c +1 -1
@@ -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
 		 */
#109 lore raw
In reply to Greg Kroah-Hartman

Hi

Quoted 1 line · Greg Kroah-Hartman

This is the start of the stable review cycle for the 3.10.6 release.

[…]

Quoted 2 lines

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 www.kernel.org (www.kernel.org)... 198.145.20.140, 149.20.4.69
Connecting to www.kernel.org (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

author maintainer
#110 lore raw
Quoted 23 lines · Stefan Lippers-Hollmann

Hi

Quoted 1 line · Greg Kroah-Hartman

This is the start of the stable review cycle for the 3.10.6 release.

[…]

Quoted 2 lines

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 www.kernel.org (www.kernel.org)... 198.145.20.140, 149.20.4.69
Connecting to www.kernel.org (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.
Quoted 5 lines

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.

Quoted 3 lines

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

maintainer
#111 lore raw
In reply to Greg Kroah-Hartman
Quoted 5 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 3.10.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.

Quoted 7 lines

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

author maintainer
#112 lore raw
Quoted 14 lines · Guenter Roeck
Quoted 5 lines · Greg Kroah-Hartman

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.

Quoted 7 lines

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.

Quoted 7 lines

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.

Quoted 8 lines

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.

Quoted 5 lines

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

maintainer
#113 lore raw
Quoted 28 lines · Greg Kroah-Hartman
Quoted 14 lines · Guenter Roeck
Quoted 5 lines · Greg Kroah-Hartman

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.

Quoted 7 lines

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.

Quoted 7 lines

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.

Quoted 3 lines

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.

Quoted 8 lines
Quoted 5 lines

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

author maintainer
#114 lore raw
Quoted 46 lines · Guenter Roeck
Quoted 28 lines · Greg Kroah-Hartman
Quoted 14 lines · Guenter Roeck
Quoted 5 lines · Greg Kroah-Hartman

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.

Quoted 7 lines

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.

Quoted 7 lines

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.

Quoted 3 lines

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.

Quoted 8 lines
Quoted 5 lines

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.

Quoted 7 lines

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

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

This is the start of the stable review cycle for the 3.10.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.

Quoted 8 lines

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

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

and the diffstat can be found below.

thanks,

greg k-h

I don't see the new stable release patches on

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

author maintainer
#116 lore raw
Quoted 18 lines · Shuah Khan
Quoted 8 lines · Greg Kroah-Hartman

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.

Quoted 8 lines

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

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

and the diffstat can be found below.

thanks,

greg k-h

Quoted 7 lines

I don't see the new stable release patches on

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

#117 lore raw
Quoted 30 lines · Greg Kroah-Hartman
Quoted 18 lines · Shuah Khan
Quoted 8 lines · Greg Kroah-Hartman

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.

Quoted 8 lines

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

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

and the diffstat can be found below.

thanks,

greg k-h

Quoted 7 lines

I don't see the new stable release patches on

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.

Quoted 7 lines

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

author maintainer
#118 lore raw
Quoted 39 lines · Shuah Khan
Quoted 30 lines · Greg Kroah-Hartman
Quoted 18 lines · Shuah Khan
Quoted 8 lines · Greg Kroah-Hartman

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.

Quoted 8 lines

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

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

and the diffstat can be found below.

thanks,

greg k-h

Quoted 7 lines

I don't see the new stable release patches on

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.

Quoted 7 lines

kernel.org is now fixed, and the patches should be there within a few minutes.

thanks,

greg k-h

Quoted 8 lines

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

#119 lore raw
In reply to Greg Kroah-Hartman
Quoted 10 lines · Greg Kroah-Hartman
Quoted 9 lines · Shuah Khan
Quoted 8 lines · Greg Kroah-Hartman

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.

Quoted 9 lines
Quoted 8 lines
Quoted 8 lines

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

	kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.10.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

author maintainer
#120 lore raw
Quoted 25 lines · Shuah Khan
Quoted 10 lines · Greg Kroah-Hartman
Quoted 9 lines · Shuah Khan
Quoted 8 lines · Greg Kroah-Hartman

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.

Quoted 9 lines
Quoted 8 lines
Quoted 8 lines

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

	kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.10.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:

Quoted 8 lines

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

#121 lore raw
In reply to Greg Kroah-Hartman

Hi Greg,

Quoted 4 lines · Greg Kroah-Hartman

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

author maintainer
#122 lore raw
Quoted 8 lines · Willy Tarreau

Hi Greg,

Quoted 4 lines · Greg Kroah-Hartman

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.

Quoted 7 lines

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

#123 lore raw
Quoted 17 lines · Greg Kroah-Hartman
Quoted 8 lines · Willy Tarreau

Hi Greg,

Quoted 4 lines · Greg Kroah-Hartman

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.

Quoted 7 lines

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 :

Quoted 2 lines

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.

Quoted 2 lines

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

author maintainer
#124 lore raw
Quoted 24 lines · Willy Tarreau
Quoted 17 lines · Greg Kroah-Hartman
Quoted 8 lines · Willy Tarreau

Hi Greg,

Quoted 4 lines · Greg Kroah-Hartman

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.

Quoted 7 lines

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 :

Quoted 2 lines

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.

Quoted 7 lines
Quoted 2 lines

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

Quoted 5 lines

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

#125 lore raw
Quoted 8 lines · Greg Kroah-Hartman
Quoted 4 lines · Willy Tarreau

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

Quoted 7 lines
Quoted 5 lines

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

maintainer
#126 lore raw
In reply to Greg Kroah-Hartman
Quoted 17 lines · Greg Kroah-Hartman
Quoted 8 lines · Willy Tarreau

Hi Greg,

Quoted 4 lines · Greg Kroah-Hartman

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.

Quoted 7 lines

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 :

Quoted 6 lines

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

author maintainer
#127 lore raw
Quoted 32 lines · Guenter Roeck
Quoted 17 lines · Greg Kroah-Hartman
Quoted 8 lines · Willy Tarreau

Hi Greg,

Quoted 4 lines · Greg Kroah-Hartman

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.

Quoted 7 lines

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 :

Quoted 6 lines

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.

Quoted 7 lines

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

#128 lore raw
In reply to Greg Kroah-Hartman

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.