Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1301746 > unrolled thread

[PATCH 3.12 00/91] 3.12.52-stable review

Started byJiri Slaby <jslaby@suse.cz>
First post2016-01-05 18:50 +0100
Last post2016-01-06 09:20 +0100
Articles 20 on this page of 93 — 9 participants

Back to article view | Back to linux.kernel


Contents

  [PATCH 3.12 00/91] 3.12.52-stable review Jiri Slaby <jslaby@suse.cz> - 2016-01-05 18:50 +0100
    [PATCH 3.12 01/91] ipv6: fix tunnel error handling Jiri Slaby <jslaby@suse.cz> - 2016-01-05 18:50 +0100
      [PATCH 3.12 68/91] sctp: use the same clock as if sock source timestamps were on Jiri Slaby <jslaby@suse.cz> - 2016-01-05 19:00 +0100
      [PATCH 3.12 73/91] net: fix IP early demux races Jiri Slaby <jslaby@suse.cz> - 2016-01-05 19:00 +0100
      [PATCH 3.12 62/91] USB: cp210x: Remove CP2110 ID from compatibility list Jiri Slaby <jslaby@suse.cz> - 2016-01-05 19:00 +0100
      [PATCH 3.12 81/91] ahci: add new Intel device IDs Jiri Slaby <jslaby@suse.cz> - 2016-01-05 19:00 +0100
      [PATCH 3.12 75/91] skbuff: Fix offset error in skb_reorder_vlan_header Jiri Slaby <jslaby@suse.cz> - 2016-01-05 19:00 +0100
      [PATCH 3.12 71/91] net: add validation for the socket syscall protocol argument Jiri Slaby <jslaby@suse.cz> - 2016-01-05 19:00 +0100
      [PATCH 3.12 63/91] USB: add quirk for devices with broken LPM Jiri Slaby <jslaby@suse.cz> - 2016-01-05 19:00 +0100
      [PATCH 3.12 57/91] nfs4: start callback_ident at idr 1 Jiri Slaby <jslaby@suse.cz> - 2016-01-05 19:00 +0100
      [PATCH 3.12 58/91] nfs: if we have no valid attrs, then don't declare the attribute cache valid Jiri Slaby <jslaby@suse.cz> - 2016-01-05 19:00 +0100
      [PATCH 3.12 74/91] vlan: Fix untag operations of stacked vlans with REORDER_HEADER off Jiri Slaby <jslaby@suse.cz> - 2016-01-05 19:00 +0100
      [PATCH 3.12 48/91] netfilter: ipt_rpfilter: remove the nh_scope test in rpfilter_lookup_reverse Jiri Slaby <jslaby@suse.cz> - 2016-01-05 19:00 +0100
      [PATCH 3.12 86/91] i2c: i801: add Intel Lewisburg device IDs Jiri Slaby <jslaby@suse.cz> - 2016-01-05 19:00 +0100
      [PATCH 3.12 61/91] USB: serial: Another Infineon flash loader USB ID Jiri Slaby <jslaby@suse.cz> - 2016-01-05 19:00 +0100
      [PATCH 3.12 51/91] ip6mr: call del_timer_sync() in ip6mr_free_table() Jiri Slaby <jslaby@suse.cz> - 2016-01-05 19:00 +0100
      [PATCH 3.12 60/91] USB: cdc_acm: Ignore Infineon Flash Loader utility Jiri Slaby <jslaby@suse.cz> - 2016-01-05 19:00 +0100
      [PATCH 3.12 77/91] bluetooth: Validate socket address length in sco_sock_bind(). Jiri Slaby <jslaby@suse.cz> - 2016-01-05 19:00 +0100
      [PATCH 3.12 65/91] usb: Use the USB_SS_MULT() macro to decode burst multiplier for log message Jiri Slaby <jslaby@suse.cz> - 2016-01-05 19:00 +0100
      [PATCH 3.12 69/91] sctp: update the netstamp_needed counter when copying sockets Jiri Slaby <jslaby@suse.cz> - 2016-01-05 19:00 +0100
      [PATCH 3.12 72/91] sh_eth: fix kernel oops in skb_put() Jiri Slaby <jslaby@suse.cz> - 2016-01-05 19:00 +0100
      [PATCH 3.12 64/91] USB: whci-hcd: add check for dma mapping error Jiri Slaby <jslaby@suse.cz> - 2016-01-05 19:00 +0100
      [PATCH 3.12 76/91] pptp: verify sockaddr_len in pptp_bind() and pptp_connect() Jiri Slaby <jslaby@suse.cz> - 2016-01-05 19:00 +0100
      [PATCH 3.12 91/91] HID: dragonrise: fix HID Descriptor for 0x0006 PID Jiri Slaby <jslaby@suse.cz> - 2016-01-05 19:00 +0100
      [PATCH 3.12 87/91] cdrom: Random writing support for BD-RE media Jiri Slaby <jslaby@suse.cz> - 2016-01-05 19:00 +0100
      [PATCH 3.12 70/91] ipv6: sctp: clone options to avoid use after free Jiri Slaby <jslaby@suse.cz> - 2016-01-05 19:00 +0100
      [PATCH 3.12 59/91] ocfs2: fix umask ignored issue Jiri Slaby <jslaby@suse.cz> - 2016-01-05 19:00 +0100
      [PATCH 3.12 67/91] atl1c: Improve driver not to do order 4 GFP_ATOMIC allocation Jiri Slaby <jslaby@suse.cz> - 2016-01-05 19:00 +0100
      [PATCH 3.12 85/91] i2c: i801: Add support for Intel Broxton Jiri Slaby <jslaby@suse.cz> - 2016-01-05 19:00 +0100
      [PATCH 3.12 82/91] target/stat: print full t10_wwn.model buffer Jiri Slaby <jslaby@suse.cz> - 2016-01-05 19:00 +0100
      [PATCH 3.12 90/91] gpio/omap: raw read and write endian fix Jiri Slaby <jslaby@suse.cz> - 2016-01-05 19:00 +0100
      [PATCH 3.12 36/91] can: sja1000: clear interrupts on start Jiri Slaby <jslaby@suse.cz> - 2016-01-05 19:10 +0100
      [PATCH 3.12 29/91] mac80211: fix driver RSSI event calculations Jiri Slaby <jslaby@suse.cz> - 2016-01-05 19:10 +0100
      [PATCH 3.12 38/91] usblp: do not set TASK_INTERRUPTIBLE before lock Jiri Slaby <jslaby@suse.cz> - 2016-01-05 19:10 +0100
      [PATCH 3.12 47/91] module: Call module notifier on failure after complete_formation() Jiri Slaby <jslaby@suse.cz> - 2016-01-05 19:10 +0100
      [PATCH 3.12 27/91] x86/cpu: Call verify_cpu() after having entered long mode too Jiri Slaby <jslaby@suse.cz> - 2016-01-05 19:10 +0100
      [PATCH 3.12 32/91] staging: rtl8712: Add device ID for Sitecom WLA2100 Jiri Slaby <jslaby@suse.cz> - 2016-01-05 19:10 +0100
      [PATCH 3.12 41/91] USB: serial: option: add support for Novatel MiFi USB620L Jiri Slaby <jslaby@suse.cz> - 2016-01-05 19:10 +0100
      [PATCH 3.12 56/91] firewire: ohci: fix JMicron JMB38x IT context discovery Jiri Slaby <jslaby@suse.cz> - 2016-01-05 19:10 +0100
      [PATCH 3.12 46/91] tty: fix stall caused by missing memory barrier in drivers/tty/n_tty.c Jiri Slaby <jslaby@suse.cz> - 2016-01-05 19:10 +0100
      [PATCH 3.12 37/91] arm64: Fix compat register mappings Jiri Slaby <jslaby@suse.cz> - 2016-01-05 19:10 +0100
      [PATCH 3.12 30/91] net: mvneta: Fix CPU_MAP registers initialisation Jiri Slaby <jslaby@suse.cz> - 2016-01-05 19:10 +0100
      [PATCH 3.12 26/91] x86/setup: Fix low identity map for >= 2GB kernel range Jiri Slaby <jslaby@suse.cz> - 2016-01-05 19:10 +0100
      [PATCH 3.12 53/91] Btrfs: fix race leading to BUG_ON when running delalloc for nodatacow Jiri Slaby <jslaby@suse.cz> - 2016-01-05 19:10 +0100
      [PATCH 3.12 55/91] ext4, jbd2: ensure entering into panic after recording an error in superblock Jiri Slaby <jslaby@suse.cz> - 2016-01-05 19:10 +0100
      [PATCH 3.12 66/91] gre6: allow to update all parameters via rtnl Jiri Slaby <jslaby@suse.cz> - 2016-01-05 19:10 +0100
      [PATCH 3.12 43/91] ALSA: usb-audio: add packet size quirk for the Medeli DD305 Jiri Slaby <jslaby@suse.cz> - 2016-01-05 19:10 +0100
      [PATCH 3.12 54/91] ext4: fix potential use after free in __ext4_journal_stop Jiri Slaby <jslaby@suse.cz> - 2016-01-05 19:10 +0100
      [PATCH 3.12 24/91] ARM: common: edma: Fix channel parameter for irq callbacks Jiri Slaby <jslaby@suse.cz> - 2016-01-05 19:10 +0100
      [PATCH 3.12 14/91] net: ipmr: fix static mfc/dev leaks on table destruction Jiri Slaby <jslaby@suse.cz> - 2016-01-05 19:10 +0100
      [PATCH 3.12 39/91] usb: musb: core: fix order of arguments to ulpi write callback Jiri Slaby <jslaby@suse.cz> - 2016-01-05 19:10 +0100
      [PATCH 3.12 45/91] ALSA: usb-audio: work around CH345 input SysEx corruption Jiri Slaby <jslaby@suse.cz> - 2016-01-05 19:10 +0100
      [PATCH 3.12 40/91] USB: ti_usb_3410_5052: Add Honeywell HGI80 ID Jiri Slaby <jslaby@suse.cz> - 2016-01-05 19:10 +0100
      [PATCH 3.12 31/91] mwifiex: fix mwifiex_rdeeprom_read() Jiri Slaby <jslaby@suse.cz> - 2016-01-05 19:10 +0100
      [PATCH 3.12 52/91] Btrfs: fix race leading to incorrect item deletion when dropping extents Jiri Slaby <jslaby@suse.cz> - 2016-01-05 19:10 +0100
      [PATCH 3.12 33/91] Bluetooth: hidp: fix device disconnect on idle timeout Jiri Slaby <jslaby@suse.cz> - 2016-01-05 19:10 +0100
      [PATCH 3.12 25/91] x86/setup: Extend low identity map to cover whole kernel range Jiri Slaby <jslaby@suse.cz> - 2016-01-05 19:10 +0100
        Re: [PATCH 3.12 25/91] x86/setup: Extend low identity map to cover  whole kernel range Paolo Bonzini <pbonzini@redhat.com> - 2016-01-06 11:50 +0100
          Re: [PATCH 3.12 25/91] x86/setup: Extend low identity map to cover  whole kernel range Matt Fleming <matt@codeblueprint.co.uk> - 2016-01-06 12:10 +0100
            Re: [PATCH 3.12 25/91] x86/setup: Extend low identity map to cover  whole kernel range Luis Henriques <luis.henriques@canonical.com> - 2016-01-06 12:30 +0100
              Re: [PATCH 3.12 25/91] x86/setup: Extend low identity map to cover  whole kernel range Matt Fleming <matt@codeblueprint.co.uk> - 2016-01-06 14:40 +0100
                Re: [PATCH 3.12 25/91] x86/setup: Extend low identity map to cover  whole kernel range Luis Henriques <luis.henriques@canonical.com> - 2016-01-06 15:30 +0100
                  Re: [PATCH 3.12 25/91] x86/setup: Extend low identity map to cover  whole kernel range Matt Fleming <matt@codeblueprint.co.uk> - 2016-01-08 13:00 +0100
                    Re: [PATCH 3.12 25/91] x86/setup: Extend low identity map to cover  whole kernel range Luis Henriques <luis.henriques@canonical.com> - 2016-01-08 14:40 +0100
                  Re: [PATCH 3.12 25/91] x86/setup: Extend low identity map to cover  whole kernel range Jiri Slaby <jslaby@suse.cz> - 2016-01-09 08:10 +0100
                  Re: [PATCH 3.12 25/91] x86/setup: Extend low identity map to cover  whole kernel range Kamal Mostafa <kamal@canonical.com> - 2016-01-14 22:00 +0100
      [PATCH 3.12 34/91] Bluetooth: ath3k: Add new AR3012 0930:021c id Jiri Slaby <jslaby@suse.cz> - 2016-01-05 19:10 +0100
      [PATCH 3.12 44/91] ALSA: usb-audio: prevent CH345 multiport output SysEx corruption Jiri Slaby <jslaby@suse.cz> - 2016-01-05 19:10 +0100
      [PATCH 3.12 35/91] Bluetooth: ath3k: Add support of AR3012 0cf3:817b device Jiri Slaby <jslaby@suse.cz> - 2016-01-05 19:10 +0100
      [PATCH 3.12 28/91] x86/cpu: Fix SMAP check in PVOPS environments Jiri Slaby <jslaby@suse.cz> - 2016-01-05 19:10 +0100
      [PATCH 3.12 49/91] netfilter: ip6t_SYNPROXY: fix NULL pointer dereference Jiri Slaby <jslaby@suse.cz> - 2016-01-05 19:10 +0100
      [PATCH 3.12 42/91] USB: option: add XS Stick W100-2 from 4G Systems Jiri Slaby <jslaby@suse.cz> - 2016-01-05 19:10 +0100
      [PATCH 3.12 10/91] net: qmi_wwan: add XS Stick W100-2 from 4G Systems Jiri Slaby <jslaby@suse.cz> - 2016-01-05 19:20 +0100
      [PATCH 3.12 11/91] tcp: md5: fix lockdep annotation Jiri Slaby <jslaby@suse.cz> - 2016-01-05 19:20 +0100
      [PATCH 3.12 19/91] net/neighbour: fix crash at dumping device-agnostic proxy entries Jiri Slaby <jslaby@suse.cz> - 2016-01-05 19:20 +0100
      [PATCH 3.12 23/91] ARM: 8427/1: dma-mapping: add support for offset parameter in dma_mmap() Jiri Slaby <jslaby@suse.cz> - 2016-01-05 19:20 +0100
      [PATCH 3.12 07/91] packet: infer protocol from ethernet header if unset Jiri Slaby <jslaby@suse.cz> - 2016-01-05 19:20 +0100
      [PATCH 3.12 21/91] Bluetooth: ath3k: Add support of 04ca:300d AR3012 device Jiri Slaby <jslaby@suse.cz> - 2016-01-05 19:20 +0100
      [PATCH 3.12 08/91] sctp: translate host order to network order when setting a hmacid Jiri Slaby <jslaby@suse.cz> - 2016-01-05 19:20 +0100
      [PATCH 3.12 22/91] ARM: 8426/1: dma-mapping: add missing range check in dma_mmap() Jiri Slaby <jslaby@suse.cz> - 2016-01-05 19:20 +0100
      [PATCH 3.12 05/91] unix: avoid use-after-free in ep_remove_wait_queue Jiri Slaby <jslaby@suse.cz> - 2016-01-05 19:20 +0100
      [PATCH 3.12 02/91] MIPS: KVM: Fix ASID restoration logic Jiri Slaby <jslaby@suse.cz> - 2016-01-05 19:20 +0100
      [PATCH 3.12 20/91] ipv6: sctp: implement sctp_v6_destroy_sock() Jiri Slaby <jslaby@suse.cz> - 2016-01-05 19:20 +0100
      [PATCH 3.12 13/91] net, scm: fix PaX detected msg_controllen overflow in scm_detach_fds Jiri Slaby <jslaby@suse.cz> - 2016-01-05 19:20 +0100
      [PATCH 3.12 18/91] ipv6: add complete rcu protection around np->opt Jiri Slaby <jslaby@suse.cz> - 2016-01-05 19:20 +0100
      [PATCH 3.12 12/91] tcp: initialize tp->copied_seq in case of cross SYN connection Jiri Slaby <jslaby@suse.cz> - 2016-01-05 19:20 +0100
      [PATCH 3.12 04/91] MIPS: KVM: Uninit VCPU in vcpu_create error path Jiri Slaby <jslaby@suse.cz> - 2016-01-05 19:20 +0100
      [PATCH 3.12 06/91] packet: do skb_probe_transport_header when we actually have data Jiri Slaby <jslaby@suse.cz> - 2016-01-05 19:20 +0100
    Re: [PATCH 3.12 00/91] 3.12.52-stable review Guenter Roeck <linux@roeck-us.net> - 2016-01-05 21:50 +0100
      Re: [PATCH 3.12 00/91] 3.12.52-stable review Jiri Slaby <jslaby@suse.cz> - 2016-01-09 09:50 +0100
    Re: [PATCH 3.12 00/91] 3.12.52-stable review Shuah Khan <shuahkh@osg.samsung.com> - 2016-01-05 22:20 +0100
    Re: [PATCH 3.12 00/91] 3.12.52-stable review Nikolay Borisov <kernel@kyup.com> - 2016-01-06 08:40 +0100
      Re: [PATCH 3.12 00/91] 3.12.52-stable review Greg KH <gregkh@linuxfoundation.org> - 2016-01-06 09:20 +0100

Page 3 of 5 — ← Prev page 1 2 [3] 4 5  Next page →


#1301805 — [PATCH 3.12 37/91] arm64: Fix compat register mappings

FromJiri Slaby <jslaby@suse.cz>
Date2016-01-05 19:10 +0100
Subject[PATCH 3.12 37/91] arm64: Fix compat register mappings
Message-ID<qNEdt-6sw-23@gated-at.bofh.it>
In reply to#1301760
From: Robin Murphy <robin.murphy@arm.com>

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

===============

commit 5accd17d0eb523350c9ef754d655e379c9bb93b3 upstream.

For reasons not entirely apparent, but now enshrined in history, the
architectural mapping of AArch32 banked registers to AArch64 registers
actually orders SP_<mode> and LR_<mode> backwards compared to the
intuitive r13/r14 order, for all modes except FIQ.

Fix the compat_<reg>_<mode> macros accordingly, in the hope of avoiding
subtle bugs with KVM and AArch32 guests.

Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
---
 arch/arm64/include/asm/ptrace.h | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/arch/arm64/include/asm/ptrace.h b/arch/arm64/include/asm/ptrace.h
index 0dacbbf9458b..124cba11e108 100644
--- a/arch/arm64/include/asm/ptrace.h
+++ b/arch/arm64/include/asm/ptrace.h
@@ -70,14 +70,14 @@
 #define compat_sp	regs[13]
 #define compat_lr	regs[14]
 #define compat_sp_hyp	regs[15]
-#define compat_sp_irq	regs[16]
-#define compat_lr_irq	regs[17]
-#define compat_sp_svc	regs[18]
-#define compat_lr_svc	regs[19]
-#define compat_sp_abt	regs[20]
-#define compat_lr_abt	regs[21]
-#define compat_sp_und	regs[22]
-#define compat_lr_und	regs[23]
+#define compat_lr_irq	regs[16]
+#define compat_sp_irq	regs[17]
+#define compat_lr_svc	regs[18]
+#define compat_sp_svc	regs[19]
+#define compat_lr_abt	regs[20]
+#define compat_sp_abt	regs[21]
+#define compat_lr_und	regs[22]
+#define compat_sp_und	regs[23]
 #define compat_r8_fiq	regs[24]
 #define compat_r9_fiq	regs[25]
 #define compat_r10_fiq	regs[26]
-- 
2.6.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]


#1301806 — [PATCH 3.12 30/91] net: mvneta: Fix CPU_MAP registers initialisation

FromJiri Slaby <jslaby@suse.cz>
Date2016-01-05 19:10 +0100
Subject[PATCH 3.12 30/91] net: mvneta: Fix CPU_MAP registers initialisation
Message-ID<qNEdt-6sw-27@gated-at.bofh.it>
In reply to#1301760
From: Maxime Ripard <maxime.ripard@free-electrons.com>

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

===============

commit 2502d0ef272da7058ef303b849a2c8dc324c2e2e upstream.

The CPU_MAP register is duplicated for each CPUs at different addresses,
each instance being at a different address.

However, the code so far was using CONFIG_NR_CPUS to initialise the CPU_MAP
registers for each registers, while the SoCs embed at most 4 CPUs.

This is especially an issue with multi_v7_defconfig, where CONFIG_NR_CPUS
is currently set to 16, resulting in writes to registers that are not
CPU_MAP.

Fixes: c5aff18204da ("net: mvneta: driver for Marvell Armada 370/XP network unit")
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
---
 drivers/net/ethernet/marvell/mvneta.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
index c54868523f27..d3b8c8af5d5b 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -945,7 +945,7 @@ static void mvneta_defaults_set(struct mvneta_port *pp)
 	/* Set CPU queue access map - all CPUs have access to all RX
 	 * queues and to all TX queues
 	 */
-	for (cpu = 0; cpu < CONFIG_NR_CPUS; cpu++)
+	for_each_present_cpu(cpu)
 		mvreg_write(pp, MVNETA_CPU_MAP(cpu),
 			    (MVNETA_CPU_RXQ_ACCESS_ALL_MASK |
 			     MVNETA_CPU_TXQ_ACCESS_ALL_MASK));
-- 
2.6.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]


#1301807 — [PATCH 3.12 26/91] x86/setup: Fix low identity map for >= 2GB kernel range

FromJiri Slaby <jslaby@suse.cz>
Date2016-01-05 19:10 +0100
Subject[PATCH 3.12 26/91] x86/setup: Fix low identity map for >= 2GB kernel range
Message-ID<qNEdt-6sw-35@gated-at.bofh.it>
In reply to#1301760
From: Krzysztof Mazur <krzysiek@podlesie.net>

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

===============

commit 68accac392d859d24adcf1be3a90e41f978bd54c upstream.

The commit f5f3497cad8c extended the low identity mapping. However, if
the kernel uses more than 2 GB (VMSPLIT_2G_OPT or VMSPLIT_1G memory
split), the normal memory mapping is overwritten by the low identity
mapping causing a crash. To avoid overwritting, limit the low identity
map to cover only memory before kernel range (PAGE_OFFSET).

Fixes: f5f3497cad8c "x86/setup: Extend low identity map to cover whole kernel range
Signed-off-by: Krzysztof Mazur <krzysiek@podlesie.net>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Matt Fleming <matt.fleming@intel.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Link: http://lkml.kernel.org/r/1446815916-22105-1-git-send-email-krzysiek@podlesie.net
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
---
 arch/x86/kernel/setup.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 29ecd5e00605..3ebbd1fdc0a8 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -1161,7 +1161,7 @@ void __init setup_arch(char **cmdline_p)
 	 */
 	clone_pgd_range(initial_page_table,
 			swapper_pg_dir     + KERNEL_PGD_BOUNDARY,
-			KERNEL_PGD_PTRS);
+			min(KERNEL_PGD_PTRS, KERNEL_PGD_BOUNDARY));
 #endif
 
 	tboot_probe();
-- 
2.6.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]


#1301808 — [PATCH 3.12 53/91] Btrfs: fix race leading to BUG_ON when running delalloc for nodatacow

FromJiri Slaby <jslaby@suse.cz>
Date2016-01-05 19:10 +0100
Subject[PATCH 3.12 53/91] Btrfs: fix race leading to BUG_ON when running delalloc for nodatacow
Message-ID<qNEdt-6sw-39@gated-at.bofh.it>
In reply to#1301760
From: Filipe Manana <fdmanana@suse.com>

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

===============

commit 1d512cb77bdbda80f0dd0620a3b260d697fd581d upstream.

If we are using the NO_HOLES feature, we have a tiny time window when
running delalloc for a nodatacow inode where we can race with a concurrent
link or xattr add operation leading to a BUG_ON.

This happens because at run_delalloc_nocow() we end up casting a leaf item
of type BTRFS_INODE_[REF|EXTREF]_KEY or of type BTRFS_XATTR_ITEM_KEY to a
file extent item (struct btrfs_file_extent_item) and then analyse its
extent type field, which won't match any of the expected extent types
(values BTRFS_FILE_EXTENT_[REG|PREALLOC|INLINE]) and therefore trigger an
explicit BUG_ON(1).

The following sequence diagram shows how the race happens when running a
no-cow dellaloc range [4K, 8K[ for inode 257 and we have the following
neighbour leafs:

             Leaf X (has N items)                    Leaf Y

 [ ... (257 INODE_ITEM 0) (257 INODE_REF 256) ]  [ (257 EXTENT_DATA 8192), ... ]
              slot N - 2         slot N - 1              slot 0

 (Note the implicit hole for inode 257 regarding the [0, 8K[ range)

       CPU 1                                         CPU 2

 run_dealloc_nocow()
   btrfs_lookup_file_extent()
     --> searches for a key with value
         (257 EXTENT_DATA 4096) in the
         fs/subvol tree
     --> returns us a path with
         path->nodes[0] == leaf X and
         path->slots[0] == N

   because path->slots[0] is >=
   btrfs_header_nritems(leaf X), it
   calls btrfs_next_leaf()

   btrfs_next_leaf()
     --> releases the path

                                              hard link added to our inode,
                                              with key (257 INODE_REF 500)
                                              added to the end of leaf X,
                                              so leaf X now has N + 1 keys

     --> searches for the key
         (257 INODE_REF 256), because
         it was the last key in leaf X
         before it released the path,
         with path->keep_locks set to 1

     --> ends up at leaf X again and
         it verifies that the key
         (257 INODE_REF 256) is no longer
         the last key in the leaf, so it
         returns with path->nodes[0] ==
         leaf X and path->slots[0] == N,
         pointing to the new item with
         key (257 INODE_REF 500)

   the loop iteration of run_dealloc_nocow()
   does not break out the loop and continues
   because the key referenced in the path
   at path->nodes[0] and path->slots[0] is
   for inode 257, its type is < BTRFS_EXTENT_DATA_KEY
   and its offset (500) is less then our delalloc
   range's end (8192)

   the item pointed by the path, an inode reference item,
   is (incorrectly) interpreted as a file extent item and
   we get an invalid extent type, leading to the BUG_ON(1):

   if (extent_type == BTRFS_FILE_EXTENT_REG ||
      extent_type == BTRFS_FILE_EXTENT_PREALLOC) {
       (...)
   } else if (extent_type == BTRFS_FILE_EXTENT_INLINE) {
       (...)
   } else {
       BUG_ON(1)
   }

The same can happen if a xattr is added concurrently and ends up having
a key with an offset smaller then the delalloc's range end.

So fix this by skipping keys with a type smaller than
BTRFS_EXTENT_DATA_KEY.

Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
---
 fs/btrfs/inode.c | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index 50f08d5f9cbb..5074a1607812 100644
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -1221,8 +1221,14 @@ next_slot:
 		num_bytes = 0;
 		btrfs_item_key_to_cpu(leaf, &found_key, path->slots[0]);
 
-		if (found_key.objectid > ino ||
-		    found_key.type > BTRFS_EXTENT_DATA_KEY ||
+		if (found_key.objectid > ino)
+			break;
+		if (WARN_ON_ONCE(found_key.objectid < ino) ||
+		    found_key.type < BTRFS_EXTENT_DATA_KEY) {
+			path->slots[0]++;
+			goto next_slot;
+		}
+		if (found_key.type > BTRFS_EXTENT_DATA_KEY ||
 		    found_key.offset > end)
 			break;
 
-- 
2.6.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]


#1301809 — [PATCH 3.12 55/91] ext4, jbd2: ensure entering into panic after recording an error in superblock

FromJiri Slaby <jslaby@suse.cz>
Date2016-01-05 19:10 +0100
Subject[PATCH 3.12 55/91] ext4, jbd2: ensure entering into panic after recording an error in superblock
Message-ID<qNEdt-6sw-37@gated-at.bofh.it>
In reply to#1301760
From: Daeho Jeong <daeho.jeong@samsung.com>

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

===============

commit 4327ba52afd03fc4b5afa0ee1d774c9c5b0e85c5 upstream.

If a EXT4 filesystem utilizes JBD2 journaling and an error occurs, the
journaling will be aborted first and the error number will be recorded
into JBD2 superblock and, finally, the system will enter into the
panic state in "errors=panic" option.  But, in the rare case, this
sequence is little twisted like the below figure and it will happen
that the system enters into panic state, which means the system reset
in mobile environment, before completion of recording an error in the
journal superblock. In this case, e2fsck cannot recognize that the
filesystem failure occurred in the previous run and the corruption
wouldn't be fixed.

Task A                        Task B
ext4_handle_error()
-> jbd2_journal_abort()
  -> __journal_abort_soft()
    -> __jbd2_journal_abort_hard()
    | -> journal->j_flags |= JBD2_ABORT;
    |
    |                         __ext4_abort()
    |                         -> jbd2_journal_abort()
    |                         | -> __journal_abort_soft()
    |                         |   -> if (journal->j_flags & JBD2_ABORT)
    |                         |           return;
    |                         -> panic()
    |
    -> jbd2_journal_update_sb_errno()

Tested-by: Hobin Woo <hobin.woo@samsung.com>
Signed-off-by: Daeho Jeong <daeho.jeong@samsung.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
---
 fs/ext4/super.c      | 12 ++++++++++--
 fs/jbd2/journal.c    |  6 +++++-
 include/linux/jbd2.h |  1 +
 3 files changed, 16 insertions(+), 3 deletions(-)

diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index d520064ceddb..49f45464518f 100644
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -404,9 +404,13 @@ static void ext4_handle_error(struct super_block *sb)
 		smp_wmb();
 		sb->s_flags |= MS_RDONLY;
 	}
-	if (test_opt(sb, ERRORS_PANIC))
+	if (test_opt(sb, ERRORS_PANIC)) {
+		if (EXT4_SB(sb)->s_journal &&
+		  !(EXT4_SB(sb)->s_journal->j_flags & JBD2_REC_ERR))
+			return;
 		panic("EXT4-fs (device %s): panic forced after error\n",
 			sb->s_id);
+	}
 }
 
 void __ext4_error(struct super_block *sb, const char *function,
@@ -585,8 +589,12 @@ void __ext4_abort(struct super_block *sb, const char *function,
 			jbd2_journal_abort(EXT4_SB(sb)->s_journal, -EIO);
 		save_error_info(sb, function, line);
 	}
-	if (test_opt(sb, ERRORS_PANIC))
+	if (test_opt(sb, ERRORS_PANIC)) {
+		if (EXT4_SB(sb)->s_journal &&
+		  !(EXT4_SB(sb)->s_journal->j_flags & JBD2_REC_ERR))
+			return;
 		panic("EXT4-fs panic from previous error\n");
+	}
 }
 
 void __ext4_msg(struct super_block *sb,
diff --git a/fs/jbd2/journal.c b/fs/jbd2/journal.c
index 2ebb7aadb381..e2d9856a015a 100644
--- a/fs/jbd2/journal.c
+++ b/fs/jbd2/journal.c
@@ -2090,8 +2090,12 @@ static void __journal_abort_soft (journal_t *journal, int errno)
 
 	__jbd2_journal_abort_hard(journal);
 
-	if (errno)
+	if (errno) {
 		jbd2_journal_update_sb_errno(journal);
+		write_lock(&journal->j_state_lock);
+		journal->j_flags |= JBD2_REC_ERR;
+		write_unlock(&journal->j_state_lock);
+	}
 }
 
 /**
diff --git a/include/linux/jbd2.h b/include/linux/jbd2.h
index 385593d748f6..e137e962834b 100644
--- a/include/linux/jbd2.h
+++ b/include/linux/jbd2.h
@@ -1007,6 +1007,7 @@ struct journal_s
 #define JBD2_ABORT_ON_SYNCDATA_ERR	0x040	/* Abort the journal on file
 						 * data write error in ordered
 						 * mode */
+#define JBD2_REC_ERR	0x080	/* The errno in the sb has been recorded */
 
 /*
  * Function declarations for the journaling transaction and buffer
-- 
2.6.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]


#1301810 — [PATCH 3.12 66/91] gre6: allow to update all parameters via rtnl

FromJiri Slaby <jslaby@suse.cz>
Date2016-01-05 19:10 +0100
Subject[PATCH 3.12 66/91] gre6: allow to update all parameters via rtnl
Message-ID<qNEdu-6sw-45@gated-at.bofh.it>
In reply to#1301760
From: Nicolas Dichtel <nicolas.dichtel@6wind.com>

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

===============

[ Upstream commit 6a61d4dbf4f54b5683e0f1e58d873cecca7cb977 ]

Parameters were updated only if the kernel was unable to find the tunnel
with the new parameters, ie only if core pamareters were updated (keys,
addr, link, type).
Now it's possible to update ttl, hoplimit, flowinfo and flags.

Fixes: c12b395a4664 ("gre: Support GRE over IPv6")
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
---
 net/ipv6/ip6_gre.c | 8 +++-----
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/net/ipv6/ip6_gre.c b/net/ipv6/ip6_gre.c
index b2e4c77d9a8c..f719c51369fc 100644
--- a/net/ipv6/ip6_gre.c
+++ b/net/ipv6/ip6_gre.c
@@ -1546,13 +1546,11 @@ static int ip6gre_changelink(struct net_device *dev, struct nlattr *tb[],
 			return -EEXIST;
 	} else {
 		t = nt;
-
-		ip6gre_tunnel_unlink(ign, t);
-		ip6gre_tnl_change(t, &p, !tb[IFLA_MTU]);
-		ip6gre_tunnel_link(ign, t);
-		netdev_state_change(dev);
 	}
 
+	ip6gre_tunnel_unlink(ign, t);
+	ip6gre_tnl_change(t, &p, !tb[IFLA_MTU]);
+	ip6gre_tunnel_link(ign, t);
 	return 0;
 }
 
-- 
2.6.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]


#1301811 — [PATCH 3.12 43/91] ALSA: usb-audio: add packet size quirk for the Medeli DD305

FromJiri Slaby <jslaby@suse.cz>
Date2016-01-05 19:10 +0100
Subject[PATCH 3.12 43/91] ALSA: usb-audio: add packet size quirk for the Medeli DD305
Message-ID<qNEdu-6sw-47@gated-at.bofh.it>
In reply to#1301760
From: Clemens Ladisch <clemens@ladisch.de>

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

===============

commit 98d362becb6621bebdda7ed0eac7ad7ec6c37898 upstream.

Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
---
 sound/usb/midi.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/sound/usb/midi.c b/sound/usb/midi.c
index c7aa71ee775b..fa9028e79dba 100644
--- a/sound/usb/midi.c
+++ b/sound/usb/midi.c
@@ -1326,6 +1326,7 @@ static int snd_usbmidi_out_endpoint_create(struct snd_usb_midi* umidi,
 		 * Various chips declare a packet size larger than 4 bytes, but
 		 * do not actually work with larger packets:
 		 */
+	case USB_ID(0x0a67, 0x5011): /* Medeli DD305 */
 	case USB_ID(0x0a92, 0x1020): /* ESI M4U */
 	case USB_ID(0x1430, 0x474b): /* RedOctane GH MIDI INTERFACE */
 	case USB_ID(0x15ca, 0x0101): /* Textech USB Midi Cable */
-- 
2.6.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]


#1301812 — [PATCH 3.12 54/91] ext4: fix potential use after free in __ext4_journal_stop

FromJiri Slaby <jslaby@suse.cz>
Date2016-01-05 19:10 +0100
Subject[PATCH 3.12 54/91] ext4: fix potential use after free in __ext4_journal_stop
Message-ID<qNEdt-6sw-41@gated-at.bofh.it>
In reply to#1301760
From: Lukas Czerner <lczerner@redhat.com>

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

===============

commit 6934da9238da947628be83635e365df41064b09b upstream.

There is a use-after-free possibility in __ext4_journal_stop() in the
case that we free the handle in the first jbd2_journal_stop() because
we're referencing handle->h_err afterwards. This was introduced in
9705acd63b125dee8b15c705216d7186daea4625 and it is wrong. Fix it by
storing the handle->h_err value beforehand and avoid referencing
potentially freed handle.

Fixes: 9705acd63b125dee8b15c705216d7186daea4625
Signed-off-by: Lukas Czerner <lczerner@redhat.com>
Reviewed-by: Andreas Dilger <adilger@dilger.ca>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
---
 fs/ext4/ext4_jbd2.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/fs/ext4/ext4_jbd2.c b/fs/ext4/ext4_jbd2.c
index ff42208417b9..0b3af57acaef 100644
--- a/fs/ext4/ext4_jbd2.c
+++ b/fs/ext4/ext4_jbd2.c
@@ -88,13 +88,13 @@ int __ext4_journal_stop(const char *where, unsigned int line, handle_t *handle)
 		return 0;
 	}
 
+	err = handle->h_err;
 	if (!handle->h_transaction) {
-		err = jbd2_journal_stop(handle);
-		return handle->h_err ? handle->h_err : err;
+		rc = jbd2_journal_stop(handle);
+		return err ? err : rc;
 	}
 
 	sb = handle->h_transaction->t_journal->j_private;
-	err = handle->h_err;
 	rc = jbd2_journal_stop(handle);
 
 	if (!err)
-- 
2.6.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]


#1301813 — [PATCH 3.12 24/91] ARM: common: edma: Fix channel parameter for irq callbacks

FromJiri Slaby <jslaby@suse.cz>
Date2016-01-05 19:10 +0100
Subject[PATCH 3.12 24/91] ARM: common: edma: Fix channel parameter for irq callbacks
Message-ID<qNEdu-6sw-55@gated-at.bofh.it>
In reply to#1301760
From: Peter Ujfalusi <peter.ujfalusi@ti.com>

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

===============

commit 696d8b70c09dd421c4d037fab04341e5b30585cf upstream.

In case when the interrupt happened for the second eDMA the channel
number was incorrectly passed to the client driver.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
---
 arch/arm/common/edma.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index 8e1a0245907f..bfe3d7a6250d 100644
--- a/arch/arm/common/edma.c
+++ b/arch/arm/common/edma.c
@@ -404,7 +404,8 @@ static irqreturn_t dma_irq_handler(int irq, void *data)
 					BIT(slot));
 			if (edma_cc[ctlr]->intr_data[channel].callback)
 				edma_cc[ctlr]->intr_data[channel].callback(
-					channel, DMA_COMPLETE,
+					EDMA_CTLR_CHAN(ctlr, channel),
+					DMA_COMPLETE,
 					edma_cc[ctlr]->intr_data[channel].data);
 		}
 	} while (sh_ipr);
@@ -458,7 +459,8 @@ static irqreturn_t dma_ccerr_handler(int irq, void *data)
 					if (edma_cc[ctlr]->intr_data[k].
 								callback) {
 						edma_cc[ctlr]->intr_data[k].
-						callback(k,
+						callback(
+						EDMA_CTLR_CHAN(ctlr, k),
 						DMA_CC_ERROR,
 						edma_cc[ctlr]->intr_data
 						[k].data);
-- 
2.6.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]


#1301814 — [PATCH 3.12 14/91] net: ipmr: fix static mfc/dev leaks on table destruction

FromJiri Slaby <jslaby@suse.cz>
Date2016-01-05 19:10 +0100
Subject[PATCH 3.12 14/91] net: ipmr: fix static mfc/dev leaks on table destruction
Message-ID<qNEdu-6sw-51@gated-at.bofh.it>
In reply to#1301760
From: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>

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

===============

[ Upstream commit 0e615e9601a15efeeb8942cf7cd4dadba0c8c5a7 ]

When destroying an mrt table the static mfc entries and the static
devices are kept, which leads to devices that can never be destroyed
(because of refcnt taken) and leaked memory, for example:
unreferenced object 0xffff880034c144c0 (size 192):
  comm "mfc-broken", pid 4777, jiffies 4320349055 (age 46001.964s)
  hex dump (first 32 bytes):
    98 53 f0 34 00 88 ff ff 98 53 f0 34 00 88 ff ff  .S.4.....S.4....
    ef 0a 0a 14 01 02 03 04 00 00 00 00 01 00 00 00  ................
  backtrace:
    [<ffffffff815c1b9e>] kmemleak_alloc+0x4e/0xb0
    [<ffffffff811ea6e0>] kmem_cache_alloc+0x190/0x300
    [<ffffffff815931cb>] ip_mroute_setsockopt+0x5cb/0x910
    [<ffffffff8153d575>] do_ip_setsockopt.isra.11+0x105/0xff0
    [<ffffffff8153e490>] ip_setsockopt+0x30/0xa0
    [<ffffffff81564e13>] raw_setsockopt+0x33/0x90
    [<ffffffff814d1e14>] sock_common_setsockopt+0x14/0x20
    [<ffffffff814d0b51>] SyS_setsockopt+0x71/0xc0
    [<ffffffff815cdbf6>] entry_SYSCALL_64_fastpath+0x16/0x7a
    [<ffffffffffffffff>] 0xffffffffffffffff

Make sure that everything is cleaned on netns destruction.

Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Reviewed-by: Cong Wang <cwang@twopensource.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
---
 net/ipv4/ipmr.c | 15 ++++++++-------
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/net/ipv4/ipmr.c b/net/ipv4/ipmr.c
index a99f914dd021..2f8de5f9c032 100644
--- a/net/ipv4/ipmr.c
+++ b/net/ipv4/ipmr.c
@@ -136,7 +136,7 @@ static int __ipmr_fill_mroute(struct mr_table *mrt, struct sk_buff *skb,
 			      struct mfc_cache *c, struct rtmsg *rtm);
 static void mroute_netlink_event(struct mr_table *mrt, struct mfc_cache *mfc,
 				 int cmd);
-static void mroute_clean_tables(struct mr_table *mrt);
+static void mroute_clean_tables(struct mr_table *mrt, bool all);
 static void ipmr_expire_process(unsigned long arg);
 
 #ifdef CONFIG_IP_MROUTE_MULTIPLE_TABLES
@@ -348,7 +348,7 @@ static struct mr_table *ipmr_new_table(struct net *net, u32 id)
 static void ipmr_free_table(struct mr_table *mrt)
 {
 	del_timer_sync(&mrt->ipmr_expire_timer);
-	mroute_clean_tables(mrt);
+	mroute_clean_tables(mrt, true);
 	kfree(mrt);
 }
 
@@ -1199,7 +1199,7 @@ static int ipmr_mfc_add(struct net *net, struct mr_table *mrt,
  *	Close the multicast socket, and clear the vif tables etc
  */
 
-static void mroute_clean_tables(struct mr_table *mrt)
+static void mroute_clean_tables(struct mr_table *mrt, bool all)
 {
 	int i;
 	LIST_HEAD(list);
@@ -1208,8 +1208,9 @@ static void mroute_clean_tables(struct mr_table *mrt)
 	/* Shut down all active vif entries */
 
 	for (i = 0; i < mrt->maxvif; i++) {
-		if (!(mrt->vif_table[i].flags & VIFF_STATIC))
-			vif_delete(mrt, i, 0, &list);
+		if (!all && (mrt->vif_table[i].flags & VIFF_STATIC))
+			continue;
+		vif_delete(mrt, i, 0, &list);
 	}
 	unregister_netdevice_many(&list);
 
@@ -1217,7 +1218,7 @@ static void mroute_clean_tables(struct mr_table *mrt)
 
 	for (i = 0; i < MFC_LINES; i++) {
 		list_for_each_entry_safe(c, next, &mrt->mfc_cache_array[i], list) {
-			if (c->mfc_flags & MFC_STATIC)
+			if (!all && (c->mfc_flags & MFC_STATIC))
 				continue;
 			list_del_rcu(&c->list);
 			mroute_netlink_event(mrt, c, RTM_DELROUTE);
@@ -1252,7 +1253,7 @@ static void mrtsock_destruct(struct sock *sk)
 						    NETCONFA_IFINDEX_ALL,
 						    net->ipv4.devconf_all);
 			RCU_INIT_POINTER(mrt->mroute_sk, NULL);
-			mroute_clean_tables(mrt);
+			mroute_clean_tables(mrt, false);
 		}
 	}
 	rtnl_unlock();
-- 
2.6.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]


#1301815 — [PATCH 3.12 39/91] usb: musb: core: fix order of arguments to ulpi write callback

FromJiri Slaby <jslaby@suse.cz>
Date2016-01-05 19:10 +0100
Subject[PATCH 3.12 39/91] usb: musb: core: fix order of arguments to ulpi write callback
Message-ID<qNEdu-6sw-57@gated-at.bofh.it>
In reply to#1301760
From: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>

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

===============

commit 705e63d2b29c8bbf091119084544d353bda70393 upstream.

There is a bit of a mess in the order of arguments to the ulpi write
callback. There is

	int ulpi_write(struct ulpi *ulpi, u8 addr, u8 val)

in drivers/usb/common/ulpi.c;

	struct usb_phy_io_ops {
		...
		int (*write)(struct usb_phy *x, u32 val, u32 reg);
	}

in include/linux/usb/phy.h.

The callback registered by the musb driver has to comply to the latter,
but up to now had "offset" first which effectively made the function
broken for correct users. So flip the order and while at it also
switch to the parameter names of struct usb_phy_io_ops's write.

Fixes: ffb865b1e460 ("usb: musb: add ulpi access operations")
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
---
 drivers/usb/musb/musb_core.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 3a63ec105045..64f342f6ab3e 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -133,7 +133,7 @@ static inline struct musb *dev_to_musb(struct device *dev)
 /*-------------------------------------------------------------------------*/
 
 #ifndef CONFIG_BLACKFIN
-static int musb_ulpi_read(struct usb_phy *phy, u32 offset)
+static int musb_ulpi_read(struct usb_phy *phy, u32 reg)
 {
 	void __iomem *addr = phy->io_priv;
 	int	i = 0;
@@ -152,7 +152,7 @@ static int musb_ulpi_read(struct usb_phy *phy, u32 offset)
 	 * ULPICarKitControlDisableUTMI after clearing POWER_SUSPENDM.
 	 */
 
-	musb_writeb(addr, MUSB_ULPI_REG_ADDR, (u8)offset);
+	musb_writeb(addr, MUSB_ULPI_REG_ADDR, (u8)reg);
 	musb_writeb(addr, MUSB_ULPI_REG_CONTROL,
 			MUSB_ULPI_REG_REQ | MUSB_ULPI_RDN_WR);
 
@@ -177,7 +177,7 @@ out:
 	return ret;
 }
 
-static int musb_ulpi_write(struct usb_phy *phy, u32 offset, u32 data)
+static int musb_ulpi_write(struct usb_phy *phy, u32 val, u32 reg)
 {
 	void __iomem *addr = phy->io_priv;
 	int	i = 0;
@@ -192,8 +192,8 @@ static int musb_ulpi_write(struct usb_phy *phy, u32 offset, u32 data)
 	power &= ~MUSB_POWER_SUSPENDM;
 	musb_writeb(addr, MUSB_POWER, power);
 
-	musb_writeb(addr, MUSB_ULPI_REG_ADDR, (u8)offset);
-	musb_writeb(addr, MUSB_ULPI_REG_DATA, (u8)data);
+	musb_writeb(addr, MUSB_ULPI_REG_ADDR, (u8)reg);
+	musb_writeb(addr, MUSB_ULPI_REG_DATA, (u8)val);
 	musb_writeb(addr, MUSB_ULPI_REG_CONTROL, MUSB_ULPI_REG_REQ);
 
 	while (!(musb_readb(addr, MUSB_ULPI_REG_CONTROL)
-- 
2.6.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]


#1301816 — [PATCH 3.12 45/91] ALSA: usb-audio: work around CH345 input SysEx corruption

FromJiri Slaby <jslaby@suse.cz>
Date2016-01-05 19:10 +0100
Subject[PATCH 3.12 45/91] ALSA: usb-audio: work around CH345 input SysEx corruption
Message-ID<qNEdu-6sw-59@gated-at.bofh.it>
In reply to#1301760
From: Clemens Ladisch <clemens@ladisch.de>

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

===============

commit a91e627e3f0ed820b11d86cdc04df38f65f33a70 upstream.

One of the many faults of the QinHeng CH345 USB MIDI interface chip is
that it does not handle received SysEx messages correctly -- every second
event packet has a wrong code index number, which is the one from the last
seen message, instead of 4.  For example, the two messages "FE F0 01 02 03
04 05 06 07 08 09 0A 0B 0C 0D 0E F7" result in the following event
packets:

correct:       CH345:
0F FE 00 00    0F FE 00 00
04 F0 01 02    04 F0 01 02
04 03 04 05    0F 03 04 05
04 06 07 08    04 06 07 08
04 09 0A 0B    0F 09 0A 0B
04 0C 0D 0E    04 0C 0D 0E
05 F7 00 00    05 F7 00 00

A class-compliant driver must interpret an event packet with CIN 15 as
having a single data byte, so the other two bytes would be ignored.  The
message received by the host would then be missing two bytes out of six;
in this example, "F0 01 02 03 06 07 08 09 0C 0D 0E F7".

These corrupted SysEx event packages contain only data bytes, while the
CH345 uses event packets with a correct CIN value only for messages with
a status byte, so it is possible to distinguish between these two cases by
checking for the presence of this status byte.

(Other bugs in the CH345's input handling, such as the corruption resulting
from running status, cannot be worked around.)

Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
---
 sound/usb/midi.c | 42 ++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 42 insertions(+)

diff --git a/sound/usb/midi.c b/sound/usb/midi.c
index 966051f530bd..9123fc518f07 100644
--- a/sound/usb/midi.c
+++ b/sound/usb/midi.c
@@ -174,6 +174,8 @@ struct snd_usb_midi_in_endpoint {
 		u8 running_status_length;
 	} ports[0x10];
 	u8 seen_f5;
+	bool in_sysex;
+	u8 last_cin;
 	u8 error_resubmit;
 	int current_port;
 };
@@ -465,6 +467,39 @@ static void snd_usbmidi_maudio_broken_running_status_input(
 }
 
 /*
+ * QinHeng CH345 is buggy: every second packet inside a SysEx has not CIN 4
+ * but the previously seen CIN, but still with three data bytes.
+ */
+static void ch345_broken_sysex_input(struct snd_usb_midi_in_endpoint *ep,
+				     uint8_t *buffer, int buffer_length)
+{
+	unsigned int i, cin, length;
+
+	for (i = 0; i + 3 < buffer_length; i += 4) {
+		if (buffer[i] == 0 && i > 0)
+			break;
+		cin = buffer[i] & 0x0f;
+		if (ep->in_sysex &&
+		    cin == ep->last_cin &&
+		    (buffer[i + 1 + (cin == 0x6)] & 0x80) == 0)
+			cin = 0x4;
+#if 0
+		if (buffer[i + 1] == 0x90) {
+			/*
+			 * Either a corrupted running status or a real note-on
+			 * message; impossible to detect reliably.
+			 */
+		}
+#endif
+		length = snd_usbmidi_cin_length[cin];
+		snd_usbmidi_input_data(ep, 0, &buffer[i + 1], length);
+		ep->in_sysex = cin == 0x4;
+		if (!ep->in_sysex)
+			ep->last_cin = cin;
+	}
+}
+
+/*
  * CME protocol: like the standard protocol, but SysEx commands are sent as a
  * single USB packet preceded by a 0x0F byte.
  */
@@ -650,6 +685,12 @@ static struct usb_protocol_ops snd_usbmidi_cme_ops = {
 	.output_packet = snd_usbmidi_output_standard_packet,
 };
 
+static struct usb_protocol_ops snd_usbmidi_ch345_broken_sysex_ops = {
+	.input = ch345_broken_sysex_input,
+	.output = snd_usbmidi_standard_output,
+	.output_packet = snd_usbmidi_output_standard_packet,
+};
+
 /*
  * AKAI MPD16 protocol:
  *
@@ -2292,6 +2333,7 @@ int snd_usbmidi_create(struct snd_card *card,
 		err = snd_usbmidi_detect_per_port_endpoints(umidi, endpoints);
 		break;
 	case QUIRK_MIDI_CH345:
+		umidi->usb_protocol_ops = &snd_usbmidi_ch345_broken_sysex_ops;
 		err = snd_usbmidi_detect_per_port_endpoints(umidi, endpoints);
 		break;
 	default:
-- 
2.6.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]


#1301817 — [PATCH 3.12 40/91] USB: ti_usb_3410_5052: Add Honeywell HGI80 ID

FromJiri Slaby <jslaby@suse.cz>
Date2016-01-05 19:10 +0100
Subject[PATCH 3.12 40/91] USB: ti_usb_3410_5052: Add Honeywell HGI80 ID
Message-ID<qNEdu-6sw-53@gated-at.bofh.it>
In reply to#1301760
From: David Woodhouse <dwmw2@infradead.org>

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

===============

commit 1bcb49e663f88bccee35b8688e6a3da2bea31fd4 upstream.

The Honeywell HGI80 is a wireless interface to the evohome connected
thermostat. It uses a TI 3410 USB-serial port.

Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
---
 drivers/usb/serial/ti_usb_3410_5052.c | 2 ++
 drivers/usb/serial/ti_usb_3410_5052.h | 4 ++++
 2 files changed, 6 insertions(+)

diff --git a/drivers/usb/serial/ti_usb_3410_5052.c b/drivers/usb/serial/ti_usb_3410_5052.c
index c9a35697ebe9..11b402935fbd 100644
--- a/drivers/usb/serial/ti_usb_3410_5052.c
+++ b/drivers/usb/serial/ti_usb_3410_5052.c
@@ -160,6 +160,7 @@ static struct usb_device_id ti_id_table_3410[] = {
 	{ USB_DEVICE(ABBOTT_VENDOR_ID, ABBOTT_STEREO_PLUG_ID) },
 	{ USB_DEVICE(ABBOTT_VENDOR_ID, ABBOTT_STRIP_PORT_ID) },
 	{ USB_DEVICE(TI_VENDOR_ID, FRI2_PRODUCT_ID) },
+	{ USB_DEVICE(HONEYWELL_VENDOR_ID, HONEYWELL_HGI80_PRODUCT_ID) },
 	{ }	/* terminator */
 };
 
@@ -192,6 +193,7 @@ static struct usb_device_id ti_id_table_combined[] = {
 	{ USB_DEVICE(ABBOTT_VENDOR_ID, ABBOTT_PRODUCT_ID) },
 	{ USB_DEVICE(ABBOTT_VENDOR_ID, ABBOTT_STRIP_PORT_ID) },
 	{ USB_DEVICE(TI_VENDOR_ID, FRI2_PRODUCT_ID) },
+	{ USB_DEVICE(HONEYWELL_VENDOR_ID, HONEYWELL_HGI80_PRODUCT_ID) },
 	{ }	/* terminator */
 };
 
diff --git a/drivers/usb/serial/ti_usb_3410_5052.h b/drivers/usb/serial/ti_usb_3410_5052.h
index 4a2423e84d55..98f35c656c02 100644
--- a/drivers/usb/serial/ti_usb_3410_5052.h
+++ b/drivers/usb/serial/ti_usb_3410_5052.h
@@ -56,6 +56,10 @@
 #define ABBOTT_PRODUCT_ID		ABBOTT_STEREO_PLUG_ID
 #define ABBOTT_STRIP_PORT_ID		0x3420
 
+/* Honeywell vendor and product IDs */
+#define HONEYWELL_VENDOR_ID		0x10ac
+#define HONEYWELL_HGI80_PRODUCT_ID	0x0102  /* Honeywell HGI80 */
+
 /* Commands */
 #define TI_GET_VERSION			0x01
 #define TI_GET_PORT_STATUS		0x02
-- 
2.6.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]


#1301818 — [PATCH 3.12 31/91] mwifiex: fix mwifiex_rdeeprom_read()

FromJiri Slaby <jslaby@suse.cz>
Date2016-01-05 19:10 +0100
Subject[PATCH 3.12 31/91] mwifiex: fix mwifiex_rdeeprom_read()
Message-ID<qNEdu-6sw-65@gated-at.bofh.it>
In reply to#1301760
From: Dan Carpenter <dan.carpenter@oracle.com>

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

===============

commit 1f9c6e1bc1ba5f8a10fcd6e99d170954d7c6d382 upstream.

There were several bugs here.

1)  The done label was in the wrong place so we didn't copy any
    information out when there was no command given.

2)  We were using PAGE_SIZE as the size of the buffer instead of
    "PAGE_SIZE - pos".

3)  snprintf() returns the number of characters that would have been
    printed if there were enough space.  If there was not enough space
    (and we had fixed the memory corruption bug #2) then it would result
    in an information leak when we do simple_read_from_buffer().  I've
    changed it to use scnprintf() instead.

I also removed the initialization at the start of the function, because
I thought it made the code a little more clear.

Fixes: 5e6e3a92b9a4 ('wireless: mwifiex: initial commit for Marvell mwifiex driver')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
---
 drivers/net/wireless/mwifiex/debugfs.c | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/net/wireless/mwifiex/debugfs.c b/drivers/net/wireless/mwifiex/debugfs.c
index a5f9875cfd6e..f84e5d7e8bbe 100644
--- a/drivers/net/wireless/mwifiex/debugfs.c
+++ b/drivers/net/wireless/mwifiex/debugfs.c
@@ -637,7 +637,7 @@ mwifiex_rdeeprom_read(struct file *file, char __user *ubuf,
 		(struct mwifiex_private *) file->private_data;
 	unsigned long addr = get_zeroed_page(GFP_KERNEL);
 	char *buf = (char *) addr;
-	int pos = 0, ret = 0, i;
+	int pos, ret, i;
 	u8 value[MAX_EEPROM_DATA];
 
 	if (!buf)
@@ -645,7 +645,7 @@ mwifiex_rdeeprom_read(struct file *file, char __user *ubuf,
 
 	if (saved_offset == -1) {
 		/* No command has been given */
-		pos += snprintf(buf, PAGE_SIZE, "0");
+		pos = snprintf(buf, PAGE_SIZE, "0");
 		goto done;
 	}
 
@@ -654,17 +654,17 @@ mwifiex_rdeeprom_read(struct file *file, char __user *ubuf,
 				  (u16) saved_bytes, value);
 	if (ret) {
 		ret = -EINVAL;
-		goto done;
+		goto out_free;
 	}
 
-	pos += snprintf(buf, PAGE_SIZE, "%d %d ", saved_offset, saved_bytes);
+	pos = snprintf(buf, PAGE_SIZE, "%d %d ", saved_offset, saved_bytes);
 
 	for (i = 0; i < saved_bytes; i++)
-		pos += snprintf(buf + strlen(buf), PAGE_SIZE, "%d ", value[i]);
-
-	ret = simple_read_from_buffer(ubuf, count, ppos, buf, pos);
+		pos += scnprintf(buf + pos, PAGE_SIZE - pos, "%d ", value[i]);
 
 done:
+	ret = simple_read_from_buffer(ubuf, count, ppos, buf, pos);
+out_free:
 	free_page(addr);
 	return ret;
 }
-- 
2.6.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]


#1301820 — [PATCH 3.12 52/91] Btrfs: fix race leading to incorrect item deletion when dropping extents

FromJiri Slaby <jslaby@suse.cz>
Date2016-01-05 19:10 +0100
Subject[PATCH 3.12 52/91] Btrfs: fix race leading to incorrect item deletion when dropping extents
Message-ID<qNEdv-6sw-69@gated-at.bofh.it>
In reply to#1301760
From: Filipe Manana <fdmanana@suse.com>

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

===============

commit aeafbf8486c9e2bd53f5cc3c10c0b7fd7149d69c upstream.

While running a stress test I got the following warning triggered:

  [191627.672810] ------------[ cut here ]------------
  [191627.673949] WARNING: CPU: 8 PID: 8447 at fs/btrfs/file.c:779 __btrfs_drop_extents+0x391/0xa50 [btrfs]()
  (...)
  [191627.701485] Call Trace:
  [191627.702037]  [<ffffffff8145f077>] dump_stack+0x4f/0x7b
  [191627.702992]  [<ffffffff81095de5>] ? console_unlock+0x356/0x3a2
  [191627.704091]  [<ffffffff8104b3b0>] warn_slowpath_common+0xa1/0xbb
  [191627.705380]  [<ffffffffa0664499>] ? __btrfs_drop_extents+0x391/0xa50 [btrfs]
  [191627.706637]  [<ffffffff8104b46d>] warn_slowpath_null+0x1a/0x1c
  [191627.707789]  [<ffffffffa0664499>] __btrfs_drop_extents+0x391/0xa50 [btrfs]
  [191627.709155]  [<ffffffff8115663c>] ? cache_alloc_debugcheck_after.isra.32+0x171/0x1d0
  [191627.712444]  [<ffffffff81155007>] ? kmemleak_alloc_recursive.constprop.40+0x16/0x18
  [191627.714162]  [<ffffffffa06570c9>] insert_reserved_file_extent.constprop.40+0x83/0x24e [btrfs]
  [191627.715887]  [<ffffffffa065422b>] ? start_transaction+0x3bb/0x610 [btrfs]
  [191627.717287]  [<ffffffffa065b604>] btrfs_finish_ordered_io+0x273/0x4e2 [btrfs]
  [191627.728865]  [<ffffffffa065b888>] finish_ordered_fn+0x15/0x17 [btrfs]
  [191627.730045]  [<ffffffffa067d688>] normal_work_helper+0x14c/0x32c [btrfs]
  [191627.731256]  [<ffffffffa067d96a>] btrfs_endio_write_helper+0x12/0x14 [btrfs]
  [191627.732661]  [<ffffffff81061119>] process_one_work+0x24c/0x4ae
  [191627.733822]  [<ffffffff810615b0>] worker_thread+0x206/0x2c2
  [191627.734857]  [<ffffffff810613aa>] ? process_scheduled_works+0x2f/0x2f
  [191627.736052]  [<ffffffff810613aa>] ? process_scheduled_works+0x2f/0x2f
  [191627.737349]  [<ffffffff810669a6>] kthread+0xef/0xf7
  [191627.738267]  [<ffffffff810f3b3a>] ? time_hardirqs_on+0x15/0x28
  [191627.739330]  [<ffffffff810668b7>] ? __kthread_parkme+0xad/0xad
  [191627.741976]  [<ffffffff81465592>] ret_from_fork+0x42/0x70
  [191627.743080]  [<ffffffff810668b7>] ? __kthread_parkme+0xad/0xad
  [191627.744206] ---[ end trace bbfddacb7aaada8d ]---

  $ cat -n fs/btrfs/file.c
  691  int __btrfs_drop_extents(struct btrfs_trans_handle *trans,
  (...)
  758                  btrfs_item_key_to_cpu(leaf, &key, path->slots[0]);
  759                  if (key.objectid > ino ||
  760                      key.type > BTRFS_EXTENT_DATA_KEY || key.offset >= end)
  761                          break;
  762
  763                  fi = btrfs_item_ptr(leaf, path->slots[0],
  764                                      struct btrfs_file_extent_item);
  765                  extent_type = btrfs_file_extent_type(leaf, fi);
  766
  767                  if (extent_type == BTRFS_FILE_EXTENT_REG ||
  768                      extent_type == BTRFS_FILE_EXTENT_PREALLOC) {
  (...)
  774                  } else if (extent_type == BTRFS_FILE_EXTENT_INLINE) {
  (...)
  778                  } else {
  779                          WARN_ON(1);
  780                          extent_end = search_start;
  781                  }
  (...)

This happened because the item we were processing did not match a file
extent item (its key type != BTRFS_EXTENT_DATA_KEY), and even on this
case we cast the item to a struct btrfs_file_extent_item pointer and
then find a type field value that does not match any of the expected
values (BTRFS_FILE_EXTENT_[REG|PREALLOC|INLINE]). This scenario happens
due to a tiny time window where a race can happen as exemplified below.
For example, consider the following scenario where we're using the
NO_HOLES feature and we have the following two neighbour leafs:

               Leaf X (has N items)                    Leaf Y

[ ... (257 INODE_ITEM 0) (257 INODE_REF 256) ]  [ (257 EXTENT_DATA 8192), ... ]
          slot N - 2         slot N - 1              slot 0

Our inode 257 has an implicit hole in the range [0, 8K[ (implicit rather
than explicit because NO_HOLES is enabled). Now if our inode has an
ordered extent for the range [4K, 8K[ that is finishing, the following
can happen:

          CPU 1                                       CPU 2

  btrfs_finish_ordered_io()
    insert_reserved_file_extent()
      __btrfs_drop_extents()
         Searches for the key
          (257 EXTENT_DATA 4096) through
          btrfs_lookup_file_extent()

         Key not found and we get a path where
         path->nodes[0] == leaf X and
         path->slots[0] == N

         Because path->slots[0] is >=
         btrfs_header_nritems(leaf X), we call
         btrfs_next_leaf()

         btrfs_next_leaf() releases the path

                                                  inserts key
                                                  (257 INODE_REF 4096)
                                                  at the end of leaf X,
                                                  leaf X now has N + 1 keys,
                                                  and the new key is at
                                                  slot N

         btrfs_next_leaf() searches for
         key (257 INODE_REF 256), with
         path->keep_locks set to 1,
         because it was the last key it
         saw in leaf X

           finds it in leaf X again and
           notices it's no longer the last
           key of the leaf, so it returns 0
           with path->nodes[0] == leaf X and
           path->slots[0] == N (which is now
           < btrfs_header_nritems(leaf X)),
           pointing to the new key
           (257 INODE_REF 4096)

         __btrfs_drop_extents() casts the
         item at path->nodes[0], slot
         path->slots[0], to a struct
         btrfs_file_extent_item - it does
         not skip keys for the target
         inode with a type less than
         BTRFS_EXTENT_DATA_KEY
         (BTRFS_INODE_REF_KEY < BTRFS_EXTENT_DATA_KEY)

         sees a bogus value for the type
         field triggering the WARN_ON in
         the trace shown above, and sets
         extent_end = search_start (4096)

         does the if-then-else logic to
         fixup 0 length extent items created
         by a past bug from hole punching:

           if (extent_end == key.offset &&
               extent_end >= search_start)
               goto delete_extent_item;

         that evaluates to true and it ends
         up deleting the key pointed to by
         path->slots[0], (257 INODE_REF 4096),
         from leaf X

The same could happen for example for a xattr that ends up having a key
with an offset value that matches search_start (very unlikely but not
impossible).

So fix this by ensuring that keys smaller than BTRFS_EXTENT_DATA_KEY are
skipped, never casted to struct btrfs_file_extent_item and never deleted
by accident. Also protect against the unexpected case of getting a key
for a lower inode number by skipping that key and issuing a warning.

Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
---
 fs/btrfs/file.c | 16 ++++++++++++----
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/fs/btrfs/file.c b/fs/btrfs/file.c
index 9663f6600973..f0cd2f2fe0af 100644
--- a/fs/btrfs/file.c
+++ b/fs/btrfs/file.c
@@ -746,8 +746,16 @@ next_slot:
 		}
 
 		btrfs_item_key_to_cpu(leaf, &key, path->slots[0]);
-		if (key.objectid > ino ||
-		    key.type > BTRFS_EXTENT_DATA_KEY || key.offset >= end)
+
+		if (key.objectid > ino)
+			break;
+		if (WARN_ON_ONCE(key.objectid < ino) ||
+		    key.type < BTRFS_EXTENT_DATA_KEY) {
+			ASSERT(del_nr == 0);
+			path->slots[0]++;
+			goto next_slot;
+		}
+		if (key.type > BTRFS_EXTENT_DATA_KEY || key.offset >= end)
 			break;
 
 		fi = btrfs_item_ptr(leaf, path->slots[0],
@@ -765,8 +773,8 @@ next_slot:
 			extent_end = key.offset +
 				btrfs_file_extent_inline_len(leaf, fi);
 		} else {
-			WARN_ON(1);
-			extent_end = search_start;
+			/* can't happen */
+			BUG();
 		}
 
 		if (extent_end <= search_start) {
-- 
2.6.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]


#1301822 — [PATCH 3.12 33/91] Bluetooth: hidp: fix device disconnect on idle timeout

FromJiri Slaby <jslaby@suse.cz>
Date2016-01-05 19:10 +0100
Subject[PATCH 3.12 33/91] Bluetooth: hidp: fix device disconnect on idle timeout
Message-ID<qNEdv-6sw-75@gated-at.bofh.it>
In reply to#1301760
From: David Herrmann <dh.herrmann@gmail.com>

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

===============

commit 660f0fc07d21114549c1862e67e78b1cf0c90c29 upstream.

The HIDP specs define an idle-timeout which automatically disconnects a
device. This has always been implemented in the HIDP layer and forced a
synchronous shutdown of the hidp-scheduler. This works just fine, but
lacks a forced disconnect on the underlying l2cap channels. This has been
broken since:

    commit 5205185d461d5902325e457ca80bd421127b7308
    Author: David Herrmann <dh.herrmann@gmail.com>
    Date:   Sat Apr 6 20:28:47 2013 +0200

        Bluetooth: hidp: remove old session-management

The old session-management always forced an l2cap error on the ctrl/intr
channels when shutting down. The new session-management skips this, as we
don't want to enforce channel policy on the caller. In other words, if
user-space removes an HIDP device, the underlying channels (which are
*owned* and *referenced* by user-space) are still left active. User-space
needs to call shutdown(2) or close(2) to release them.

Unfortunately, this does not work with idle-timeouts. There is no way to
signal user-space that the HIDP layer has been stopped. The API simply
does not support any event-passing except for poll(2). Hence, we restore
old behavior and force EUNATCH on the sockets if the HIDP layer is
disconnected due to idle-timeouts (behavior of explicit disconnects
remains unmodified). User-space can still call

    getsockopt(..., SO_ERROR, ...)

..to retrieve the EUNATCH error and clear sk_err. Hence, the channels can
still be re-used (which nobody does so far, though). Therefore, the API
still supports the new behavior, but with this patch it's also compatible
to the old implicit channel shutdown.

Reported-by: Mark Haun <haunma@keteu.org>
Reported-by: Luiz Augusto von Dentz <luiz.dentz@gmail.com>
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
---
 net/bluetooth/hidp/core.c | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/net/bluetooth/hidp/core.c b/net/bluetooth/hidp/core.c
index bdc35a7a7fee..49637fb491a9 100644
--- a/net/bluetooth/hidp/core.c
+++ b/net/bluetooth/hidp/core.c
@@ -415,6 +415,20 @@ static void hidp_idle_timeout(unsigned long arg)
 {
 	struct hidp_session *session = (struct hidp_session *) arg;
 
+	/* The HIDP user-space API only contains calls to add and remove
+	 * devices. There is no way to forward events of any kind. Therefore,
+	 * we have to forcefully disconnect a device on idle-timeouts. This is
+	 * unfortunate and weird API design, but it is spec-compliant and
+	 * required for backwards-compatibility. Hence, on idle-timeout, we
+	 * signal driver-detach events, so poll() will be woken up with an
+	 * error-condition on both sockets.
+	 */
+
+	session->intr_sock->sk->sk_err = EUNATCH;
+	session->ctrl_sock->sk->sk_err = EUNATCH;
+	wake_up_interruptible(sk_sleep(session->intr_sock->sk));
+	wake_up_interruptible(sk_sleep(session->ctrl_sock->sk));
+
 	hidp_session_terminate(session);
 }
 
-- 
2.6.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]


#1301823 — [PATCH 3.12 25/91] x86/setup: Extend low identity map to cover whole kernel range

FromJiri Slaby <jslaby@suse.cz>
Date2016-01-05 19:10 +0100
Subject[PATCH 3.12 25/91] x86/setup: Extend low identity map to cover whole kernel range
Message-ID<qNEdv-6sw-77@gated-at.bofh.it>
In reply to#1301760
From: Paolo Bonzini <pbonzini@redhat.com>

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

===============

commit f5f3497cad8c8416a74b9aaceb127908755d020a upstream.

On 32-bit systems, the initial_page_table is reused by
efi_call_phys_prolog as an identity map to call
SetVirtualAddressMap.  efi_call_phys_prolog takes care of
converting the current CPU's GDT to a physical address too.

For PAE kernels the identity mapping is achieved by aliasing the
first PDPE for the kernel memory mapping into the first PDPE
of initial_page_table.  This makes the EFI stub's trick "just work".

However, for non-PAE kernels there is no guarantee that the identity
mapping in the initial_page_table extends as far as the GDT; in this
case, accesses to the GDT will cause a page fault (which quickly becomes
a triple fault).  Fix this by copying the kernel mappings from
swapper_pg_dir to initial_page_table twice, both at PAGE_OFFSET and at
identity mapping.

For some reason, this is only reproducible with QEMU's dynamic translation
mode, and not for example with KVM.  However, even under KVM one can clearly
see that the page table is bogus:

    $ qemu-system-i386 -pflash OVMF.fd -M q35 vmlinuz0 -s -S -daemonize
    $ gdb
    (gdb) target remote localhost:1234
    (gdb) hb *0x02858f6f
    Hardware assisted breakpoint 1 at 0x2858f6f
    (gdb) c
    Continuing.

    Breakpoint 1, 0x02858f6f in ?? ()
    (gdb) monitor info registers
    ...
    GDT=     0724e000 000000ff
    IDT=     fffbb000 000007ff
    CR0=0005003b CR2=ff896000 CR3=032b7000 CR4=00000690
    ...

The page directory is sane:

    (gdb) x/4wx 0x32b7000
    0x32b7000:	0x03398063	0x03399063	0x0339a063	0x0339b063
    (gdb) x/4wx 0x3398000
    0x3398000:	0x00000163	0x00001163	0x00002163	0x00003163
    (gdb) x/4wx 0x3399000
    0x3399000:	0x00400003	0x00401003	0x00402003	0x00403003

but our particular page directory entry is empty:

    (gdb) x/1wx 0x32b7000 + (0x724e000 >> 22) * 4
    0x32b7070:	0x00000000

[ It appears that you can skate past this issue if you don't receive
  any interrupts while the bogus GDT pointer is loaded, or if you avoid
  reloading the segment registers in general.

  Andy Lutomirski provides some additional insight:

   "AFAICT it's entirely permissible for the GDTR and/or LDT
    descriptor to point to unmapped memory.  Any attempt to use them
    (segment loads, interrupts, IRET, etc) will try to access that memory
    as if the access came from CPL 0 and, if the access fails, will
    generate a valid page fault with CR2 pointing into the GDT or
    LDT."

  Up until commit 23a0d4e8fa6d ("efi: Disable interrupts around EFI
  calls, not in the epilog/prolog calls") interrupts were disabled
  around the prolog and epilog calls, and the functional GDT was
  re-installed before interrupts were re-enabled.

  Which explains why no one has hit this issue until now. ]

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Reported-by: Laszlo Ersek <lersek@redhat.com>
Cc: <stable@vger.kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Andy Lutomirski <luto@amacapital.net>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
[ Updated changelog. ]
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
---
 arch/x86/kernel/setup.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index f0de6294b955..29ecd5e00605 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -1154,6 +1154,14 @@ void __init setup_arch(char **cmdline_p)
 	clone_pgd_range(initial_page_table + KERNEL_PGD_BOUNDARY,
 			swapper_pg_dir     + KERNEL_PGD_BOUNDARY,
 			KERNEL_PGD_PTRS);
+
+	/*
+	 * sync back low identity map too.  It is used for example
+	 * in the 32-bit EFI stub.
+	 */
+	clone_pgd_range(initial_page_table,
+			swapper_pg_dir     + KERNEL_PGD_BOUNDARY,
+			KERNEL_PGD_PTRS);
 #endif
 
 	tboot_probe();
-- 
2.6.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]


#1302589 — Re: [PATCH 3.12 25/91] x86/setup: Extend low identity map to cover whole kernel range

FromPaolo Bonzini <pbonzini@redhat.com>
Date2016-01-06 11:50 +0100
SubjectRe: [PATCH 3.12 25/91] x86/setup: Extend low identity map to cover whole kernel range
Message-ID<qNTPf-8o8-87@gated-at.bofh.it>
In reply to#1301823
This bug

On 05/01/2016 18:46, Jiri Slaby wrote:
> From: Paolo Bonzini <pbonzini@redhat.com>
> 
> 3.12-stable review patch.  If anyone has any objections, please let me know.
> 
> ===============
> 
> commit f5f3497cad8c8416a74b9aaceb127908755d020a upstream.
> 
> On 32-bit systems, the initial_page_table is reused by
> efi_call_phys_prolog as an identity map to call
> SetVirtualAddressMap.  efi_call_phys_prolog takes care of
> converting the current CPU's GDT to a physical address too.
> 
> For PAE kernels the identity mapping is achieved by aliasing the
> first PDPE for the kernel memory mapping into the first PDPE
> of initial_page_table.  This makes the EFI stub's trick "just work".
> 
> However, for non-PAE kernels there is no guarantee that the identity
> mapping in the initial_page_table extends as far as the GDT; in this
> case, accesses to the GDT will cause a page fault (which quickly becomes
> a triple fault).  Fix this by copying the kernel mappings from
> swapper_pg_dir to initial_page_table twice, both at PAGE_OFFSET and at
> identity mapping.
> 
> For some reason, this is only reproducible with QEMU's dynamic translation
> mode, and not for example with KVM.  However, even under KVM one can clearly
> see that the page table is bogus:
> 
>     $ qemu-system-i386 -pflash OVMF.fd -M q35 vmlinuz0 -s -S -daemonize
>     $ gdb
>     (gdb) target remote localhost:1234
>     (gdb) hb *0x02858f6f
>     Hardware assisted breakpoint 1 at 0x2858f6f
>     (gdb) c
>     Continuing.
> 
>     Breakpoint 1, 0x02858f6f in ?? ()
>     (gdb) monitor info registers
>     ...
>     GDT=     0724e000 000000ff
>     IDT=     fffbb000 000007ff
>     CR0=0005003b CR2=ff896000 CR3=032b7000 CR4=00000690
>     ...
> 
> The page directory is sane:
> 
>     (gdb) x/4wx 0x32b7000
>     0x32b7000:	0x03398063	0x03399063	0x0339a063	0x0339b063
>     (gdb) x/4wx 0x3398000
>     0x3398000:	0x00000163	0x00001163	0x00002163	0x00003163
>     (gdb) x/4wx 0x3399000
>     0x3399000:	0x00400003	0x00401003	0x00402003	0x00403003
> 
> but our particular page directory entry is empty:
> 
>     (gdb) x/1wx 0x32b7000 + (0x724e000 >> 22) * 4
>     0x32b7070:	0x00000000
> 
> [ It appears that you can skate past this issue if you don't receive
>   any interrupts while the bogus GDT pointer is loaded, or if you avoid
>   reloading the segment registers in general.
> 
>   Andy Lutomirski provides some additional insight:
> 
>    "AFAICT it's entirely permissible for the GDTR and/or LDT
>     descriptor to point to unmapped memory.  Any attempt to use them
>     (segment loads, interrupts, IRET, etc) will try to access that memory
>     as if the access came from CPL 0 and, if the access fails, will
>     generate a valid page fault with CR2 pointing into the GDT or
>     LDT."
> 
>   Up until commit 23a0d4e8fa6d ("efi: Disable interrupts around EFI
>   calls, not in the epilog/prolog calls") interrupts were disabled
>   around the prolog and epilog calls, and the functional GDT was
>   re-installed before interrupts were re-enabled.
> 
>   Which explains why no one has hit this issue until now. ]

Without testing the problematic scenario explicitly (32-bit UEFI
kernel), I think this patch and 26/91 should not be backported to
kernels that do not have 23a0d4e8fa6d.

Paolo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]


#1302651 — Re: [PATCH 3.12 25/91] x86/setup: Extend low identity map to cover whole kernel range

FromMatt Fleming <matt@codeblueprint.co.uk>
Date2016-01-06 12:10 +0100
SubjectRe: [PATCH 3.12 25/91] x86/setup: Extend low identity map to cover whole kernel range
Message-ID<qNU8z-jS-57@gated-at.bofh.it>
In reply to#1302589
On Wed, 06 Jan, at 11:47:20AM, Paolo Bonzini wrote:
> 
> Without testing the problematic scenario explicitly (32-bit UEFI
> kernel), I think this patch and 26/91 should not be backported to
> kernels that do not have 23a0d4e8fa6d.

I tend to agree.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]


#1302695 — Re: [PATCH 3.12 25/91] x86/setup: Extend low identity map to cover whole kernel range

FromLuis Henriques <luis.henriques@canonical.com>
Date2016-01-06 12:30 +0100
SubjectRe: [PATCH 3.12 25/91] x86/setup: Extend low identity map to cover whole kernel range
Message-ID<qNUrU-sc-11@gated-at.bofh.it>
In reply to#1302651
On Wed, Jan 06, 2016 at 11:00:31AM +0000, Matt Fleming wrote:
> On Wed, 06 Jan, at 11:47:20AM, Paolo Bonzini wrote:
> > 
> > Without testing the problematic scenario explicitly (32-bit UEFI
> > kernel), I think this patch and 26/91 should not be backported to
> > kernels that do not have 23a0d4e8fa6d.
> 
> I tend to agree.

I can see these 2 commits in kernels as old as 3.10 (which definitely do
not include 23a0d4e8fa6d).  Does this mean these should be reverted from
stable kernels that already include these patches?  Or would you rather
recommend to backport 23a0d4e8fa6d?

Cheers,
--
Luís
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]


Page 3 of 5 — ← Prev page 1 2 [3] 4 5  Next page →

Back to top | Article view | linux.kernel


csiph-web