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

Groups > linux.kernel > #1381489 > unrolled thread

[PATCH 3.4 00/92] 3.4.112-rc1 review

Back to article view | Back to linux.kernel

Contents

  [PATCH 3.4 00/92] 3.4.112-rc1 review lizf@kernel.org - 2016-04-18 12:50 +0200
    [PATCH 3.4 41/92] iwlwifi: dvm: fix D3 firmware PN programming lizf@kernel.org - 2016-04-18 12:50 +0200
    [PATCH 3.4 10/92] devres: fix devres_get() lizf@kernel.org - 2016-04-18 12:50 +0200
    [PATCH 3.4 19/92] SUNRPC: xs_reset_transport must mark the connection as disconnected lizf@kernel.org - 2016-04-18 12:50 +0200
    [PATCH 3.4 29/92] scsi_dh: fix randconfig build error lizf@kernel.org - 2016-04-18 12:50 +0200
    [PATCH 3.4 45/92] md/raid10: ensure device failure recorded before write request returns. lizf@kernel.org - 2016-04-18 12:50 +0200
    [PATCH 3.4 42/92] sched/core: Fix TASK_DEAD race in finish_task_switch() lizf@kernel.org - 2016-04-18 12:50 +0200
    [PATCH 3.4 16/92] DRM - radeon: Don't link train DisplayPort on HPD until we get the dpcd lizf@kernel.org - 2016-04-18 12:50 +0200
    [PATCH 3.4 24/92] hpfs: update ctime and mtime on directory modification lizf@kernel.org - 2016-04-18 12:50 +0200
    [PATCH 3.4 31/92] powerpc/MSI: Fix race condition in tearing down MSI interrupts lizf@kernel.org - 2016-04-18 12:50 +0200
    [PATCH 3.4 26/92] fs: create and use seq_show_option for escaping lizf@kernel.org - 2016-04-18 12:50 +0200
    [PATCH 3.4 22/92] Add radeon suspend/resume quirk for HP Compaq dc5750. lizf@kernel.org - 2016-04-18 12:50 +0200
    [PATCH 3.4 46/92] md/raid10: don't clear bitmap bit when bad-block-list write fails. lizf@kernel.org - 2016-04-18 12:50 +0200
    [PATCH 3.4 73/92] tty: fix stall caused by missing memory barrier in drivers/tty/n_tty.c lizf@kernel.org - 2016-04-18 13:00 +0200
    [PATCH 3.4 67/92] x86/process: Add proper bound checks in 64bit get_wchan() lizf@kernel.org - 2016-04-18 13:00 +0200
    [PATCH 3.4 51/92] spi: Fix documentation of spi_alloc_master() lizf@kernel.org - 2016-04-18 13:00 +0200
    [PATCH 3.4 64/92] x86/xen: Do not clip xen_e820_map to xen_e820_map_entries when sanitizing map lizf@kernel.org - 2016-04-18 13:00 +0200
    [PATCH 3.4 69/92] mm: hugetlbfs: skip shared VMAs when unmapping private pages to satisfy a fault lizf@kernel.org - 2016-04-18 13:00 +0200
    [PATCH 3.4 85/92] mm: make sendfile(2) killable lizf@kernel.org - 2016-04-18 13:00 +0200
    [PATCH 3.4 56/92] usb: Use the USB_SS_MULT() macro to get the burst multiplier. lizf@kernel.org - 2016-04-18 13:00 +0200
    [PATCH 3.4 71/92] USB: Add reset-resume quirk for two Plantronics usb headphones. lizf@kernel.org - 2016-04-18 13:00 +0200
    [PATCH 3.4 76/92] xen-blkfront: check for null drvdata in blkback_changed (XenbusStateClosing) lizf@kernel.org - 2016-04-18 13:00 +0200
    [PATCH 3.4 72/92] usb: Add device quirk for Logitech PTZ cameras lizf@kernel.org - 2016-04-18 13:00 +0200
    [PATCH 3.4 68/92] genirq: Fix race in register_irq_proc() lizf@kernel.org - 2016-04-18 13:00 +0200
    [PATCH 3.4 92/92] x86/iopl/64: Properly context-switch IOPL on Xen PV lizf@kernel.org - 2016-04-18 13:00 +0200
    [PATCH 3.4 91/92] splice: sendfile() at once fails for big files lizf@kernel.org - 2016-04-18 13:00 +0200
    [PATCH 3.4 82/92] ASoC: wm8904: Correct number of EQ registers lizf@kernel.org - 2016-04-18 13:00 +0200
    [PATCH 3.4 90/92] pipe: Fix buffer offset after partially failed read lizf@kernel.org - 2016-04-18 13:00 +0200
    [PATCH 3.4 89/92] usb: Use the USB_SS_MULT() macro to decode burst multiplier for log message lizf@kernel.org - 2016-04-18 13:00 +0200
    [PATCH 3.4 80/92] xhci: Add spurious wakeup quirk for LynxPoint-LP controllers lizf@kernel.org - 2016-04-18 13:00 +0200
    [PATCH 3.4 88/92] raid1: include bio_end_io_list in nr_queued to prevent freeze_array hang lizf@kernel.org - 2016-04-18 13:00 +0200
    [PATCH 3.4 83/92] iommu/amd: Don't clear DTE flags when modifying it lizf@kernel.org - 2016-04-18 13:00 +0200
    [PATCH 3.4 78/92] iommu/vt-d: fix range computation when making room for large pages lizf@kernel.org - 2016-04-18 13:00 +0200
    [PATCH 3.4 58/92] usb: xhci: Clear XHCI_STATE_DYING on start lizf@kernel.org - 2016-04-18 13:00 +0200
    [PATCH 3.4 52/92] btrfs: skip waiting on ordered range for special files lizf@kernel.org - 2016-04-18 13:00 +0200
    [PATCH 3.4 77/92] crypto: ahash - ensure statesize is non-zero lizf@kernel.org - 2016-04-18 13:00 +0200
    [PATCH 3.4 87/92] mvsas: Fix NULL pointer dereference in mvs_slot_task_free lizf@kernel.org - 2016-04-18 13:00 +0200
    [PATCH 3.4 86/92] dm btree: fix leak of bufio-backed block in btree_split_beneath error path lizf@kernel.org - 2016-04-18 13:00 +0200
    [PATCH 3.4 74/92] drivers/tty: require read access for controlling terminal lizf@kernel.org - 2016-04-18 13:00 +0200
    [PATCH 3.4 60/92] cifs: use server timestamp for ntlmv2 authentication lizf@kernel.org - 2016-04-18 13:00 +0200
    [PATCH 3.4 75/92] ALSA: synth: Fix conflicting OSS device registration on AWE32 lizf@kernel.org - 2016-04-18 13:00 +0200
    [PATCH 3.4 81/92] crypto: api - Only abort operations on fatal signal lizf@kernel.org - 2016-04-18 13:00 +0200
    [PATCH 3.4 84/92] drm/nouveau/gem: return only valid domain when there's only one lizf@kernel.org - 2016-04-18 13:00 +0200
    [PATCH 3.4 61/92] ocfs2/dlm: fix deadlock when dispatch assert master lizf@kernel.org - 2016-04-18 13:00 +0200
      Re: [PATCH 3.4 61/92] ocfs2/dlm: fix deadlock when dispatch assert  master Joseph Qi <joseph.qi@huawei.com> - 2016-04-18 13:40 +0200
        Re: [PATCH 3.4 61/92] ocfs2/dlm: fix deadlock when dispatch assert  master Zefan Li <lizefan@huawei.com> - 2016-04-19 02:20 +0200
    [PATCH 3.4 79/92] xhci: handle no ping response error properly lizf@kernel.org - 2016-04-18 13:00 +0200
    [PATCH 3.4 57/92] xhci: give command abortion one more chance before killing xhci lizf@kernel.org - 2016-04-18 13:10 +0200
    [PATCH 3.4 50/92] spi: spi-pxa2xx: Check status register to determine if SSSR_TINT is disabled lizf@kernel.org - 2016-04-18 13:10 +0200
    [PATCH 3.4 48/92] md/raid1: don't clear bitmap bit when bad-block-list write fails. lizf@kernel.org - 2016-04-18 13:10 +0200
    [PATCH 3.4 43/92] IB/cm: Fix rb-tree duplicate free and use-after-free lizf@kernel.org - 2016-04-18 13:10 +0200
    [PATCH 3.4 49/92] drm: crtc: integer overflow in drm_property_create_blob() lizf@kernel.org - 2016-04-18 13:10 +0200
    [PATCH 3.4 55/92] KVM: x86: trap AMD MSRs for the TSeg base and mask lizf@kernel.org - 2016-04-18 13:10 +0200
    [PATCH 3.4 63/92] m68k: Define asmlinkage_protect lizf@kernel.org - 2016-04-18 13:10 +0200
    [PATCH 3.4 54/92] regmap: debugfs: Don't bother actually printing when calculating max length lizf@kernel.org - 2016-04-18 13:10 +0200
    [PATCH 3.4 66/92] UBI: return ENOSPC if no enough space available lizf@kernel.org - 2016-04-18 13:10 +0200
    [PATCH 3.4 59/92] xhci: change xhci 1.0 only restrictions to support xhci 1.1 lizf@kernel.org - 2016-04-18 13:10 +0200
    [PATCH 3.4 53/92] regmap: debugfs: Ensure we don't underflow when printing access masks lizf@kernel.org - 2016-04-18 13:10 +0200
    [PATCH 3.4 65/92] UBI: Validate data_size lizf@kernel.org - 2016-04-18 13:10 +0200
    [PATCH 3.4 62/92] ath9k: declare required extra tx headroom lizf@kernel.org - 2016-04-18 13:10 +0200
    [PATCH 3.4 70/92] clocksource: Fix abs() usage w/ 64bit values lizf@kernel.org - 2016-04-18 13:10 +0200
    [PATCH 3.4 47/92] md/raid1: ensure device failure recorded before write request returns. lizf@kernel.org - 2016-04-18 13:10 +0200
    [PATCH 3.4 09/92] auxdisplay: ks0108: fix refcount lizf@kernel.org - 2016-04-18 13:20 +0200
    [PATCH 3.4 25/92] crypto: ghash-clmulni: specify context size for ghash async algorithm lizf@kernel.org - 2016-04-18 13:20 +0200
    [PATCH 3.4 20/92] IB/mlx4: Use correct SL on AH query under RoCE lizf@kernel.org - 2016-04-18 13:20 +0200
    [PATCH 3.4 21/92] IB/uverbs: Fix race between ib_uverbs_open and remove_one lizf@kernel.org - 2016-04-18 13:20 +0200
    [PATCH 3.4 30/92] ARM: 8429/1: disable GCC SRA optimization lizf@kernel.org - 2016-04-18 13:20 +0200
    [PATCH 3.4 33/92] ARM: 7880/1: Clear the IT state independent of the Thumb-2 mode lizf@kernel.org - 2016-04-18 13:20 +0200
    [PATCH 3.4 13/92] usb: host: ehci-sys: delete useless bus_to_hcd conversion lizf@kernel.org - 2016-04-18 13:20 +0200
    [PATCH 3.4 40/92] md/raid0: apply base queue limits *before* disk_stack_limits lizf@kernel.org - 2016-04-18 13:20 +0200
    [PATCH 3.4 15/92] eCryptfs: Invalidate dcache entries when lower i_nlink is zero lizf@kernel.org - 2016-04-18 13:20 +0200
    [PATCH 3.4 38/92] ASoC: fix broken pxa SoC support lizf@kernel.org - 2016-04-18 13:20 +0200
    [PATCH 3.4 06/92] powerpc/rtas: Introduce rtas_get_sensor_fast() for IRQ handlers lizf@kernel.org - 2016-04-18 13:20 +0200
    [PATCH 3.4 11/92] windfarm: decrement client count when unregistering lizf@kernel.org - 2016-04-18 13:20 +0200
    [PATCH 3.4 36/92] module: Fix locking in symbol_put_addr() lizf@kernel.org - 2016-04-18 13:20 +0200
    [PATCH 3.4 17/92] of/address: Don't loop forever in of_find_matching_node_by_address(). lizf@kernel.org - 2016-04-18 13:20 +0200
    [PATCH 3.4 14/92] USB: ftdi_sio: Added custom PID for CustomWare products lizf@kernel.org - 2016-04-18 13:20 +0200
    [PATCH 3.4 23/92] IB/uverbs: reject invalid or unknown opcodes lizf@kernel.org - 2016-04-18 13:20 +0200
    [PATCH 3.4 27/92] hfs,hfsplus: cache pages correctly between bnode_create and bnode_free lizf@kernel.org - 2016-04-18 13:20 +0200
    [PATCH 3.4 05/92] PCI: Add VPD function 0 quirk for Intel Ethernet devices lizf@kernel.org - 2016-04-18 13:30 +0200
    Re: [PATCH 3.4 00/92] 3.4.112-rc1 review Guenter Roeck <linux@roeck-us.net> - 2016-04-18 18:40 +0200
      Re: [PATCH 3.4 00/92] 3.4.112-rc1 review Zefan Li <lizefan@huawei.com> - 2016-04-19 02:30 +0200

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

#1381516 — [PATCH 3.4 71/92] USB: Add reset-resume quirk for two Plantronics usb headphones.

From: Yao-Wen Mao <yaowen@google.com>

3.4.112-rc1 review patch.  If anyone has any objections, please let me know.

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


commit 8484bf2981b3d006426ac052a3642c9ce1d8d980 upstream.

These two headphones need a reset-resume quirk to properly resume to
original volume level.

Signed-off-by: Yao-Wen Mao <yaowen@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Zefan Li <lizefan@huawei.com>
---
 drivers/usb/core/quirks.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/drivers/usb/core/quirks.c b/drivers/usb/core/quirks.c
index 9fac46d..8d75403 100644
--- a/drivers/usb/core/quirks.c
+++ b/drivers/usb/core/quirks.c
@@ -73,6 +73,12 @@ static const struct usb_device_id usb_quirk_list[] = {
 	/* Philips PSC805 audio device */
 	{ USB_DEVICE(0x0471, 0x0155), .driver_info = USB_QUIRK_RESET_RESUME },
 
+	/* Plantronic Audio 655 DSP */
+	{ USB_DEVICE(0x047f, 0xc008), .driver_info = USB_QUIRK_RESET_RESUME },
+
+	/* Plantronic Audio 648 USB */
+	{ USB_DEVICE(0x047f, 0xc013), .driver_info = USB_QUIRK_RESET_RESUME },
+
 	/* Artisman Watchdog Dongle */
 	{ USB_DEVICE(0x04b4, 0x0526), .driver_info =
 			USB_QUIRK_CONFIG_INTF_STRINGS },
-- 
1.9.1

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

#1381517 — [PATCH 3.4 76/92] xen-blkfront: check for null drvdata in blkback_changed (XenbusStateClosing)

From: Cathy Avery <cathy.avery@oracle.com>

3.4.112-rc1 review patch.  If anyone has any objections, please let me know.

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


commit a54c8f0f2d7df525ff997e2afe71866a1a013064 upstream.

xen-blkfront will crash if the check to talk_to_blkback()
in blkback_changed()(XenbusStateInitWait) returns an error.
The driver data is freed and info is set to NULL. Later during
the close process via talk_to_blkback's call to xenbus_dev_fatal()
the null pointer is passed to and dereference in blkfront_closing.

Signed-off-by: Cathy Avery <cathy.avery@oracle.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Zefan Li <lizefan@huawei.com>
---
 drivers/block/xen-blkfront.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index a81cdd7..16477b2 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -1314,7 +1314,8 @@ static void blkback_changed(struct xenbus_device *dev,
 			break;
 		/* Missed the backend's Closing state -- fallthrough */
 	case XenbusStateClosing:
-		blkfront_closing(info);
+		if (info)
+			blkfront_closing(info);
 		break;
 	}
 }
-- 
1.9.1

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

#1381518 — [PATCH 3.4 72/92] usb: Add device quirk for Logitech PTZ cameras

From: Vincent Palatin <vpalatin@chromium.org>

3.4.112-rc1 review patch.  If anyone has any objections, please let me know.

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


commit 72194739f54607bbf8cfded159627a2015381557 upstream.

Add a device quirk for the Logitech PTZ Pro Camera and its sibling the
ConferenceCam CC3000e Camera.
This fixes the failed camera enumeration on some boot, particularly on
machines with fast CPU.

Tested by connecting a Logitech PTZ Pro Camera to a machine with a
Haswell Core i7-4600U CPU @ 2.10GHz, and doing thousands of reboot cycles
while recording the kernel logs and taking camera picture after each boot.
Before the patch, more than 7% of the boots show some enumeration transfer
failures and in a few of them, the kernel is giving up before actually
enumerating the webcam. After the patch, the enumeration has been correct
on every reboot.

Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Zefan Li <lizefan@huawei.com>
---
 drivers/usb/core/quirks.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/usb/core/quirks.c b/drivers/usb/core/quirks.c
index 8d75403..fd8e60e 100644
--- a/drivers/usb/core/quirks.c
+++ b/drivers/usb/core/quirks.c
@@ -49,6 +49,13 @@ static const struct usb_device_id usb_quirk_list[] = {
 	/* Microsoft LifeCam-VX700 v2.0 */
 	{ USB_DEVICE(0x045e, 0x0770), .driver_info = USB_QUIRK_RESET_RESUME },
 
+	/* Logitech ConferenceCam CC3000e */
+	{ USB_DEVICE(0x046d, 0x0847), .driver_info = USB_QUIRK_DELAY_INIT },
+	{ USB_DEVICE(0x046d, 0x0848), .driver_info = USB_QUIRK_DELAY_INIT },
+
+	/* Logitech PTZ Pro Camera */
+	{ USB_DEVICE(0x046d, 0x0853), .driver_info = USB_QUIRK_DELAY_INIT },
+
 	/* Logitech Quickcam Fusion */
 	{ USB_DEVICE(0x046d, 0x08c1), .driver_info = USB_QUIRK_RESET_RESUME },
 
-- 
1.9.1

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

#1381519 — [PATCH 3.4 68/92] genirq: Fix race in register_irq_proc()

From: Ben Hutchings <ben@decadent.org.uk>

3.4.112-rc1 review patch.  If anyone has any objections, please let me know.

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


commit 95c2b17534654829db428f11bcf4297c059a2a7e upstream.

Per-IRQ directories in procfs are created only when a handler is first
added to the irqdesc, not when the irqdesc is created.  In the case of
a shared IRQ, multiple tasks can race to create a directory.  This
race condition seems to have been present forever, but is easier to
hit with async probing.

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Link: http://lkml.kernel.org/r/1443266636.2004.2.camel@decadent.org.uk
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Zefan Li <lizefan@huawei.com>
---
 kernel/irq/proc.c | 19 +++++++++++++++++--
 1 file changed, 17 insertions(+), 2 deletions(-)

diff --git a/kernel/irq/proc.c b/kernel/irq/proc.c
index fb655f5f..15374d0 100644
--- a/kernel/irq/proc.c
+++ b/kernel/irq/proc.c
@@ -12,6 +12,7 @@
 #include <linux/seq_file.h>
 #include <linux/interrupt.h>
 #include <linux/kernel_stat.h>
+#include <linux/mutex.h>
 
 #include "internals.h"
 
@@ -326,18 +327,29 @@ void register_handler_proc(unsigned int irq, struct irqaction *action)
 
 void register_irq_proc(unsigned int irq, struct irq_desc *desc)
 {
+	static DEFINE_MUTEX(register_lock);
 	char name [MAX_NAMELEN];
 
-	if (!root_irq_dir || (desc->irq_data.chip == &no_irq_chip) || desc->dir)
+	if (!root_irq_dir || (desc->irq_data.chip == &no_irq_chip))
 		return;
 
+	/*
+	 * irq directories are registered only when a handler is
+	 * added, not when the descriptor is created, so multiple
+	 * tasks might try to register at the same time.
+	 */
+	mutex_lock(&register_lock);
+
+	if (desc->dir)
+		goto out_unlock;
+
 	memset(name, 0, MAX_NAMELEN);
 	sprintf(name, "%d", irq);
 
 	/* create /proc/irq/1234 */
 	desc->dir = proc_mkdir(name, root_irq_dir);
 	if (!desc->dir)
-		return;
+		goto out_unlock;
 
 #ifdef CONFIG_SMP
 	/* create /proc/irq/<irq>/smp_affinity */
@@ -358,6 +370,9 @@ void register_irq_proc(unsigned int irq, struct irq_desc *desc)
 
 	proc_create_data("spurious", 0444, desc->dir,
 			 &irq_spurious_proc_fops, (void *)(long)irq);
+
+out_unlock:
+	mutex_unlock(&register_lock);
 }
 
 void unregister_irq_proc(unsigned int irq, struct irq_desc *desc)
-- 
1.9.1

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

#1381521 — [PATCH 3.4 92/92] x86/iopl/64: Properly context-switch IOPL on Xen PV

From: Andy Lutomirski <luto@kernel.org>

3.4.112-rc1 review patch.  If anyone has any objections, please let me know.

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


commit b7a584598aea7ca73140cb87b40319944dd3393f upstream.

On Xen PV, regs->flags doesn't reliably reflect IOPL and the
exit-to-userspace code doesn't change IOPL.  We need to context
switch it manually.

I'm doing this without going through paravirt because this is
specific to Xen PV.  After the dust settles, we can merge this with
the 32-bit code, tidy up the iopl syscall implementation, and remove
the set_iopl pvop entirely.

Fixes XSA-171.

Reviewewd-by: Jan Beulich <JBeulich@suse.com>
Signed-off-by: Andy Lutomirski <luto@kernel.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: David Vrabel <david.vrabel@citrix.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Jan Beulich <JBeulich@suse.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/693c3bd7aeb4d3c27c92c622b7d0f554a458173c.1458162709.git.luto@kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
[ kamal: backport to 3.19-stable: no X86_FEATURE_XENPV so just call
  xen_pv_domain() directly ]
Acked-by: Andy Lutomirski <luto@kernel.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Zefan Li <lizefan@huawei.com>
---
 arch/x86/include/asm/xen/hypervisor.h |  2 ++
 arch/x86/kernel/process_64.c          | 12 ++++++++++++
 arch/x86/xen/enlighten.c              |  2 +-
 3 files changed, 15 insertions(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/xen/hypervisor.h b/arch/x86/include/asm/xen/hypervisor.h
index 66d0fff..fc500f9 100644
--- a/arch/x86/include/asm/xen/hypervisor.h
+++ b/arch/x86/include/asm/xen/hypervisor.h
@@ -72,4 +72,6 @@ static inline bool xen_x2apic_para_available(void)
 }
 #endif
 
+extern void xen_set_iopl_mask(unsigned mask);
+
 #endif /* _ASM_X86_XEN_HYPERVISOR_H */
diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c
index f6698ad..9f341bb 100644
--- a/arch/x86/kernel/process_64.c
+++ b/arch/x86/kernel/process_64.c
@@ -49,6 +49,7 @@
 #include <asm/syscalls.h>
 #include <asm/debugreg.h>
 #include <asm/switch_to.h>
+#include <asm/xen/hypervisor.h>
 
 asmlinkage extern void ret_from_fork(void);
 
@@ -419,6 +420,17 @@ __switch_to(struct task_struct *prev_p, struct task_struct *next_p)
 		     task_thread_info(prev_p)->flags & _TIF_WORK_CTXSW_PREV))
 		__switch_to_xtra(prev_p, next_p, tss);
 
+#ifdef CONFIG_XEN
+	/*
+	 * On Xen PV, IOPL bits in pt_regs->flags have no effect, and
+	 * current_pt_regs()->flags may not match the current task's
+	 * intended IOPL.  We need to switch it manually.
+	 */
+	if (unlikely(xen_pv_domain() &&
+		     prev->iopl != next->iopl))
+		xen_set_iopl_mask(next->iopl);
+#endif
+
 	return prev_p;
 }
 
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 8ade106..761c086 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -860,7 +860,7 @@ static void xen_load_sp0(struct tss_struct *tss,
 	xen_mc_issue(PARAVIRT_LAZY_CPU);
 }
 
-static void xen_set_iopl_mask(unsigned mask)
+void xen_set_iopl_mask(unsigned mask)
 {
 	struct physdev_set_iopl set_iopl;
 
-- 
1.9.1

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

#1381523 — [PATCH 3.4 91/92] splice: sendfile() at once fails for big files

From: Christophe Leroy <christophe.leroy@c-s.fr>

3.4.112-rc1 review patch.  If anyone has any objections, please let me know.

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


commit 0ff28d9f4674d781e492bcff6f32f0fe48cf0fed upstream.

Using sendfile with below small program to get MD5 sums of some files,
it appear that big files (over 64kbytes with 4k pages system) get a
wrong MD5 sum while small files get the correct sum.
This program uses sendfile() to send a file to an AF_ALG socket
for hashing.

/* md5sum2.c */
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>
#include <fcntl.h>
#include <sys/socket.h>
#include <sys/stat.h>
#include <sys/types.h>
#include <linux/if_alg.h>

int main(int argc, char **argv)
{
	int sk = socket(AF_ALG, SOCK_SEQPACKET, 0);
	struct stat st;
	struct sockaddr_alg sa = {
		.salg_family = AF_ALG,
		.salg_type = "hash",
		.salg_name = "md5",
	};
	int n;

	bind(sk, (struct sockaddr*)&sa, sizeof(sa));

	for (n = 1; n < argc; n++) {
		int size;
		int offset = 0;
		char buf[4096];
		int fd;
		int sko;
		int i;

		fd = open(argv[n], O_RDONLY);
		sko = accept(sk, NULL, 0);
		fstat(fd, &st);
		size = st.st_size;
		sendfile(sko, fd, &offset, size);
		size = read(sko, buf, sizeof(buf));
		for (i = 0; i < size; i++)
			printf("%2.2x", buf[i]);
		printf("  %s\n", argv[n]);
		close(fd);
		close(sko);
	}
	exit(0);
}

Test below is done using official linux patch files. First result is
with a software based md5sum. Second result is with the program above.

root@vgoip:~# ls -l patch-3.6.*
-rw-r--r--    1 root     root         64011 Aug 24 12:01 patch-3.6.2.gz
-rw-r--r--    1 root     root         94131 Aug 24 12:01 patch-3.6.3.gz

root@vgoip:~# md5sum patch-3.6.*
b3ffb9848196846f31b2ff133d2d6443  patch-3.6.2.gz
c5e8f687878457db77cb7158c38a7e43  patch-3.6.3.gz

root@vgoip:~# ./md5sum2 patch-3.6.*
b3ffb9848196846f31b2ff133d2d6443  patch-3.6.2.gz
5fd77b24e68bb24dcc72d6e57c64790e  patch-3.6.3.gz

After investivation, it appears that sendfile() sends the files by blocks
of 64kbytes (16 times PAGE_SIZE). The problem is that at the end of each
block, the SPLICE_F_MORE flag is missing, therefore the hashing operation
is reset as if it was the end of the file.

This patch adds SPLICE_F_MORE to the flags when more data is pending.

With the patch applied, we get the correct sums:

root@vgoip:~# md5sum patch-3.6.*
b3ffb9848196846f31b2ff133d2d6443  patch-3.6.2.gz
c5e8f687878457db77cb7158c38a7e43  patch-3.6.3.gz

root@vgoip:~# ./md5sum2 patch-3.6.*
b3ffb9848196846f31b2ff133d2d6443  patch-3.6.2.gz
c5e8f687878457db77cb7158c38a7e43  patch-3.6.3.gz

Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Signed-off-by: Jens Axboe <axboe@fb.com>
Cc: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Zefan Li <lizefan@huawei.com>
---
 fs/splice.c | 12 +++++++++++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/fs/splice.c b/fs/splice.c
index 67c5210..2864177 100644
--- a/fs/splice.c
+++ b/fs/splice.c
@@ -1165,7 +1165,7 @@ ssize_t splice_direct_to_actor(struct file *in, struct splice_desc *sd,
 	long ret, bytes;
 	umode_t i_mode;
 	size_t len;
-	int i, flags;
+	int i, flags, more;
 
 	/*
 	 * We require the input being a regular file, as we don't want to
@@ -1208,6 +1208,7 @@ ssize_t splice_direct_to_actor(struct file *in, struct splice_desc *sd,
 	 * Don't block on output, we have to drain the direct pipe.
 	 */
 	sd->flags &= ~SPLICE_F_NONBLOCK;
+	more = sd->flags & SPLICE_F_MORE;
 
 	while (len) {
 		size_t read_len;
@@ -1221,6 +1222,15 @@ ssize_t splice_direct_to_actor(struct file *in, struct splice_desc *sd,
 		sd->total_len = read_len;
 
 		/*
+		 * If more data is pending, set SPLICE_F_MORE
+		 * If this is the last data and SPLICE_F_MORE was not set
+		 * initially, clears it.
+		 */
+		if (read_len < len)
+			sd->flags |= SPLICE_F_MORE;
+		else if (!more)
+			sd->flags &= ~SPLICE_F_MORE;
+		/*
 		 * NOTE: nonblocking mode only applies to the input. We
 		 * must not do the output in nonblocking mode as then we
 		 * could get stuck data in the internal pipe:
-- 
1.9.1

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

#1381525 — [PATCH 3.4 82/92] ASoC: wm8904: Correct number of EQ registers

From: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>

3.4.112-rc1 review patch.  If anyone has any objections, please let me know.

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


commit 97aff2c03a1e4d343266adadb52313613efb027f upstream.

There are 24 EQ registers not 25, I suspect this bug came about because
the registers start at EQ1 not zero. The bug is relatively harmless as
the extra register written is an unused one.

Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Zefan Li <lizefan@huawei.com>
---
 include/sound/wm8904.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/sound/wm8904.h b/include/sound/wm8904.h
index 898be3a..6d8f8fb 100644
--- a/include/sound/wm8904.h
+++ b/include/sound/wm8904.h
@@ -119,7 +119,7 @@
 #define WM8904_MIC_REGS  2
 #define WM8904_GPIO_REGS 4
 #define WM8904_DRC_REGS  4
-#define WM8904_EQ_REGS   25
+#define WM8904_EQ_REGS   24
 
 /**
  * DRC configurations are specified with a label and a set of register
-- 
1.9.1

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

#1381526 — [PATCH 3.4 90/92] pipe: Fix buffer offset after partially failed read

From: Ben Hutchings <ben@decadent.org.uk>

3.4.112-rc1 review patch.  If anyone has any objections, please let me know.

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


Quoting the RHEL advisory:

> It was found that the fix for CVE-2015-1805 incorrectly kept buffer
> offset and buffer length in sync on a failed atomic read, potentially
> resulting in a pipe buffer state corruption. A local, unprivileged user
> could use this flaw to crash the system or leak kernel memory to user
> space. (CVE-2016-0774, Moderate)

The same flawed fix was applied to stable branches from 2.6.32.y to
3.14.y inclusive, and I was able to reproduce the issue on 3.2.y.
We need to give pipe_iov_copy_to_user() a separate offset variable
and only update the buffer offset if it succeeds.

References: https://rhn.redhat.com/errata/RHSA-2016-0103.html
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Cc: Jeffrey Vander Stoep <jeffv@google.com>
Signed-off-by: Zefan Li <lizefan@huawei.com>
---
 fs/pipe.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/fs/pipe.c b/fs/pipe.c
index abfb935..6049235 100644
--- a/fs/pipe.c
+++ b/fs/pipe.c
@@ -390,6 +390,7 @@ pipe_read(struct kiocb *iocb, const struct iovec *_iov,
 			void *addr;
 			size_t chars = buf->len, remaining;
 			int error, atomic;
+			int offset;
 
 			if (chars > total_len)
 				chars = total_len;
@@ -403,9 +404,10 @@ pipe_read(struct kiocb *iocb, const struct iovec *_iov,
 
 			atomic = !iov_fault_in_pages_write(iov, chars);
 			remaining = chars;
+			offset = buf->offset;
 redo:
 			addr = ops->map(pipe, buf, atomic);
-			error = pipe_iov_copy_to_user(iov, addr, &buf->offset,
+			error = pipe_iov_copy_to_user(iov, addr, &offset,
 						      &remaining, atomic);
 			ops->unmap(pipe, buf, addr);
 			if (unlikely(error)) {
@@ -421,6 +423,7 @@ redo:
 				break;
 			}
 			ret += chars;
+			buf->offset += chars;
 			buf->len -= chars;
 
 			/* Was it a packet buffer? Clean up and exit */
-- 
1.9.1

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

#1381527 — [PATCH 3.4 89/92] usb: Use the USB_SS_MULT() macro to decode burst multiplier for log message

From: Ben Hutchings <ben@decadent.org.uk>

3.4.112-rc1 review patch.  If anyone has any objections, please let me know.

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


commit 5377adb092664d336ac212499961cac5e8728794 upstream.

usb_parse_ss_endpoint_companion() now decodes the burst multiplier
correctly in order to check that it's <= 3, but still uses the wrong
expression if warning that it's > 3.

Fixes: ff30cbc8da42 ("usb: Use the USB_SS_MULT() macro to get the ...")
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Zefan Li <lizefan@huawei.com>
---
 drivers/usb/core/config.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/core/config.c b/drivers/usb/core/config.c
index 6baa836..bfc9b69 100644
--- a/drivers/usb/core/config.c
+++ b/drivers/usb/core/config.c
@@ -117,7 +117,8 @@ static void usb_parse_ss_endpoint_companion(struct device *ddev, int cfgno,
 		   USB_SS_MULT(desc->bmAttributes) > 3) {
 		dev_warn(ddev, "Isoc endpoint has Mult of %d in "
 				"config %d interface %d altsetting %d ep %d: "
-				"setting to 3\n", desc->bmAttributes + 1,
+				"setting to 3\n",
+				USB_SS_MULT(desc->bmAttributes),
 				cfgno, inum, asnum, ep->desc.bEndpointAddress);
 		ep->ss_ep_comp.bmAttributes = 2;
 	}
-- 
1.9.1

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

#1381528 — [PATCH 3.4 80/92] xhci: Add spurious wakeup quirk for LynxPoint-LP controllers

From: Laura Abbott <labbott@fedoraproject.org>

3.4.112-rc1 review patch.  If anyone has any objections, please let me know.

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


commit fd7cd061adcf5f7503515ba52b6a724642a839c8 upstream.

We received several reports of systems rebooting and powering on
after an attempted shutdown. Testing showed that setting
XHCI_SPURIOUS_WAKEUP quirk in addition to the XHCI_SPURIOUS_REBOOT
quirk allowed the system to shutdown as expected for LynxPoint-LP
xHCI controllers. Set the quirk back.

Note that the quirk was originally introduced for LynxPoint and
LynxPoint-LP just for this same reason. See:

commit 638298dc66ea ("xhci: Fix spurious wakeups after S5 on Haswell")

It was later limited to only concern HP machines as it caused
regression on some machines, see both bug and commit:

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=66171
commit 6962d914f317 ("xhci: Limit the spurious wakeup fix only to HP machines")

Later it was discovered that the powering on after shutdown
was limited to LynxPoint-LP (Haswell-ULT) and that some non-LP HP
machine suffered from spontaneous resume from S3 (which should
not be related to the SPURIOUS_WAKEUP quirk at all). An attempt
to fix this then removed the SPURIOUS_WAKEUP flag usage completely.

commit b45abacde3d5 ("xhci: no switching back on non-ULT Haswell")

Current understanding is that LynxPoint-LP (Haswell ULT) machines
need the SPURIOUS_WAKEUP quirk, otherwise they will restart, and
plain Lynxpoint (Haswell) machines may _not_ have the quirk
set otherwise they again will restart.

Signed-off-by: Laura Abbott <labbott@fedoraproject.org>
Cc: Takashi Iwai <tiwai@suse.de>
Cc: Oliver Neukum <oneukum@suse.com>
[Added more history to commit message -Mathias]
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Zefan Li <lizefan@huawei.com>
---
 drivers/usb/host/xhci-pci.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index 710b2e9..3053933 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -121,6 +121,7 @@ static void xhci_pci_quirks(struct device *dev, struct xhci_hcd *xhci)
 		 * PPT chipsets.
 		 */
 		xhci->quirks |= XHCI_SPURIOUS_REBOOT;
+		xhci->quirks |= XHCI_SPURIOUS_WAKEUP;
 	}
 	if (pdev->vendor == PCI_VENDOR_ID_INTEL &&
 		(pdev->device == PCI_DEVICE_ID_INTEL_SUNRISEPOINT_LP_XHCI ||
-- 
1.9.1

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

#1381529 — [PATCH 3.4 88/92] raid1: include bio_end_io_list in nr_queued to prevent freeze_array hang

From: Nate Dailey <nate.dailey@stratus.com>

3.4.112-rc1 review patch.  If anyone has any objections, please let me know.

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


commit ccfc7bf1f09d6190ef86693ddc761d5fe3fa47cb upstream.

If raid1d is handling a mix of read and write errors, handle_read_error's
call to freeze_array can get stuck.

This can happen because, though the bio_end_io_list is initially drained,
writes can be added to it via handle_write_finished as the retry_list
is processed. These writes contribute to nr_pending but are not included
in nr_queued.

If a later entry on the retry_list triggers a call to handle_read_error,
freeze array hangs waiting for nr_pending == nr_queued+extra. The writes
on the bio_end_io_list aren't included in nr_queued so the condition will
never be satisfied.

To prevent the hang, include bio_end_io_list writes in nr_queued.

There's probably a better way to handle decrementing nr_queued, but this
seemed like the safest way to avoid breaking surrounding code.

I'm happy to supply the script I used to repro this hang.

Fixes: 55ce74d4bfe1b(md/raid1: ensure device failure recorded before write request returns.)
Signed-off-by: Nate Dailey <nate.dailey@stratus.com>
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Zefan Li <lizefan@huawei.com>
---
 drivers/md/raid1.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/md/raid1.c b/drivers/md/raid1.c
index 32d1f1a..a548eed 100644
--- a/drivers/md/raid1.c
+++ b/drivers/md/raid1.c
@@ -2088,6 +2088,7 @@ static void handle_write_finished(struct r1conf *conf, struct r1bio *r1_bio)
 	if (fail) {
 		spin_lock_irq(&conf->device_lock);
 		list_add(&r1_bio->retry_list, &conf->bio_end_io_list);
+		conf->nr_queued++;
 		spin_unlock_irq(&conf->device_lock);
 		md_wakeup_thread(conf->mddev->thread);
 	} else {
@@ -2202,8 +2203,10 @@ static void raid1d(struct mddev *mddev)
 		LIST_HEAD(tmp);
 		spin_lock_irqsave(&conf->device_lock, flags);
 		if (!test_bit(MD_CHANGE_PENDING, &mddev->flags)) {
-			list_add(&tmp, &conf->bio_end_io_list);
-			list_del_init(&conf->bio_end_io_list);
+			while (!list_empty(&conf->bio_end_io_list)) {
+				list_move(conf->bio_end_io_list.prev, &tmp);
+				conf->nr_queued--;
+			}
 		}
 		spin_unlock_irqrestore(&conf->device_lock, flags);
 		while (!list_empty(&tmp)) {
-- 
1.9.1

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

#1381530 — [PATCH 3.4 83/92] iommu/amd: Don't clear DTE flags when modifying it

From: Joerg Roedel <jroedel@suse.de>

3.4.112-rc1 review patch.  If anyone has any objections, please let me know.

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


commit cbf3ccd09d683abf1cacd36e3640872ee912d99b upstream.

During device assignment/deassignment the flags in the DTE
get lost, which might cause spurious faults, for example
when the device tries to access the system management range.
Fix this by not clearing the flags with the rest of the DTE.

Reported-by: G. Richard Bellamy <rbellamy@pteradigm.com>
Tested-by: G. Richard Bellamy <rbellamy@pteradigm.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Signed-off-by: Zefan Li <lizefan@huawei.com>
---
 drivers/iommu/amd_iommu.c       | 4 ++--
 drivers/iommu/amd_iommu_types.h | 1 +
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index a55353c3..30e6d5f 100644
--- a/drivers/iommu/amd_iommu.c
+++ b/drivers/iommu/amd_iommu.c
@@ -1931,8 +1931,8 @@ static void set_dte_entry(u16 devid, struct protection_domain *domain, bool ats)
 static void clear_dte_entry(u16 devid)
 {
 	/* remove entry from the device table seen by the hardware */
-	amd_iommu_dev_table[devid].data[0] = IOMMU_PTE_P | IOMMU_PTE_TV;
-	amd_iommu_dev_table[devid].data[1] = 0;
+	amd_iommu_dev_table[devid].data[0]  = IOMMU_PTE_P | IOMMU_PTE_TV;
+	amd_iommu_dev_table[devid].data[1] &= DTE_FLAG_MASK;
 
 	amd_iommu_apply_erratum_63(devid);
 }
diff --git a/drivers/iommu/amd_iommu_types.h b/drivers/iommu/amd_iommu_types.h
index c4ffacb..42f2090 100644
--- a/drivers/iommu/amd_iommu_types.h
+++ b/drivers/iommu/amd_iommu_types.h
@@ -277,6 +277,7 @@
 #define IOMMU_PTE_IR (1ULL << 61)
 #define IOMMU_PTE_IW (1ULL << 62)
 
+#define DTE_FLAG_MASK	(0x3ffULL << 32)
 #define DTE_FLAG_IOTLB	(0x01UL << 32)
 #define DTE_FLAG_GV	(0x01ULL << 55)
 #define DTE_GLX_SHIFT	(56)
-- 
1.9.1

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

#1381531 — [PATCH 3.4 78/92] iommu/vt-d: fix range computation when making room for large pages

From: Christian Zander <christian@nervanasys.com>

3.4.112-rc1 review patch.  If anyone has any objections, please let me know.

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


commit ba2374fd2bf379f933773811fdb06cb6a5445f41 upstream.

In preparation for the installation of a large page, any small page
tables that may still exist in the target IOV address range are
removed.  However, if a scatter/gather list entry is large enough to
fit more than one large page, the address space for any subsequent
large pages is not cleared of conflicting small page tables.

This can cause legitimate mapping requests to fail with errors of the
form below, potentially followed by a series of IOMMU faults:

ERROR: DMA PTE for vPFN 0xfde00 already set (to 7f83a4003 not 7e9e00083)

In this example, a 4MiB scatter/gather list entry resulted in the
successful installation of a large page @ vPFN 0xfdc00, followed by
a failed attempt to install another large page @ vPFN 0xfde00, due to
the presence of a pointer to a small page table @ 0x7f83a4000.

To address this problem, compute the number of large pages that fit
into a given scatter/gather list entry, and use it to derive the
last vPFN covered by the large page(s).

Signed-off-by: Christian Zander <christian@nervanasys.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
[bwh: Backported to 3.2:
 - Add the lvl_pages variable, added by an earlier commit upstream
 - Also change arguments to dma_pte_clear_range(), which is called by
   dma_pte_free_pagetable() upstream]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Zefan Li <lizefan@huawei.com>
---
 drivers/iommu/intel-iommu.c | 19 +++++++++++++------
 1 file changed, 13 insertions(+), 6 deletions(-)

diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 28af276..bd400f2 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -1827,13 +1827,20 @@ static int __domain_mapping(struct dmar_domain *domain, unsigned long iov_pfn,
 				return -ENOMEM;
 			/* It is large page*/
 			if (largepage_lvl > 1) {
+				unsigned long nr_superpages, end_pfn, lvl_pages;
+
 				pteval |= DMA_PTE_LARGE_PAGE;
-				/* Ensure that old small page tables are removed to make room
-				   for superpage, if they exist. */
-				dma_pte_clear_range(domain, iov_pfn,
-						    iov_pfn + lvl_to_nr_pages(largepage_lvl) - 1);
-				dma_pte_free_pagetable(domain, iov_pfn,
-						       iov_pfn + lvl_to_nr_pages(largepage_lvl) - 1);
+				lvl_pages = lvl_to_nr_pages(largepage_lvl);
+
+				nr_superpages = sg_res / lvl_pages;
+				end_pfn = iov_pfn + nr_superpages * lvl_pages - 1;
+
+				/*
+				 * Ensure that old small page tables are
+				 * removed to make room for superpage(s).
+				 */
+				dma_pte_clear_range(domain, iov_pfn, end_pfn);
+				dma_pte_free_pagetable(domain, iov_pfn, end_pfn);
 			} else {
 				pteval &= ~(uint64_t)DMA_PTE_LARGE_PAGE;
 			}
-- 
1.9.1

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

#1381532 — [PATCH 3.4 58/92] usb: xhci: Clear XHCI_STATE_DYING on start

From: Roger Quadros <rogerq@ti.com>

3.4.112-rc1 review patch.  If anyone has any objections, please let me know.

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


commit e5bfeab0ad515b4f6df39fe716603e9dc6d3dfd0 upstream.

For whatever reason if XHCI died in the previous instant
then it will never recover on the next xhci_start unless we
clear the DYING flag.

Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Zefan Li <lizefan@huawei.com>
---
 drivers/usb/host/xhci.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index fd52e1e..88be7a5 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -141,7 +141,8 @@ static int xhci_start(struct xhci_hcd *xhci)
 				"waited %u microseconds.\n",
 				XHCI_MAX_HALT_USEC);
 	if (!ret)
-		xhci->xhc_state &= ~XHCI_STATE_HALTED;
+		xhci->xhc_state &= ~(XHCI_STATE_HALTED | XHCI_STATE_DYING);
+
 	return ret;
 }
 
-- 
1.9.1

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

#1381533 — [PATCH 3.4 52/92] btrfs: skip waiting on ordered range for special files

From: Jeff Mahoney <jeffm@suse.com>

3.4.112-rc1 review patch.  If anyone has any objections, please let me know.

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


commit a30e577c96f59b1e1678ea5462432b09bf7d5cbc upstream.

In btrfs_evict_inode, we properly truncate the page cache for evicted
inodes but then we call btrfs_wait_ordered_range for every inode as well.
It's the right thing to do for regular files but results in incorrect
behavior for device inodes for block devices.

filemap_fdatawrite_range gets called with inode->i_mapping which gets
resolved to the block device inode before getting passed to
wbc_attach_fdatawrite_inode and ultimately to inode_to_bdi.  What happens
next depends on whether there's an open file handle associated with the
inode.  If there is, we write to the block device, which is unexpected
behavior.  If there isn't, we through normally and inode->i_data is used.
We can also end up racing against open/close which can result in crashes
when i_mapping points to a block device inode that has been closed.

Since there can't be any page cache associated with special file inodes,
it's safe to skip the btrfs_wait_ordered_range call entirely and avoid
the problem.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=100911
Tested-by: Christoph Biedl <linux-kernel.bfrz@manchmal.in-ulm.de>
Signed-off-by: Jeff Mahoney <jeffm@suse.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Zefan Li <lizefan@huawei.com>
---
 fs/btrfs/inode.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index 9e51325..575c190 100644
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -3685,7 +3685,8 @@ void btrfs_evict_inode(struct inode *inode)
 		goto no_delete;
 	}
 	/* do we really want it for ->i_nlink > 0 and zero btrfs_root_refs? */
-	btrfs_wait_ordered_range(inode, 0, (u64)-1);
+	if (!special_file(inode->i_mode))
+		btrfs_wait_ordered_range(inode, 0, (u64)-1);
 
 	if (root->fs_info->log_root_recovering) {
 		BUG_ON(!list_empty(&BTRFS_I(inode)->i_orphan));
-- 
1.9.1

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

#1381534 — [PATCH 3.4 77/92] crypto: ahash - ensure statesize is non-zero

From: Russell King <rmk+kernel@arm.linux.org.uk>

3.4.112-rc1 review patch.  If anyone has any objections, please let me know.

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


commit 8996eafdcbad149ac0f772fb1649fbb75c482a6a upstream.

Unlike shash algorithms, ahash drivers must implement export
and import as their descriptors may contain hardware state and
cannot be exported as is.  Unfortunately some ahash drivers did
not provide them and end up causing crashes with algif_hash.

This patch adds a check to prevent these drivers from registering
ahash algorithms until they are fixed.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Zefan Li <lizefan@huawei.com>
---
 crypto/ahash.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/crypto/ahash.c b/crypto/ahash.c
index 0ec05fe..5824191 100644
--- a/crypto/ahash.c
+++ b/crypto/ahash.c
@@ -462,7 +462,8 @@ static int ahash_prepare_alg(struct ahash_alg *alg)
 	struct crypto_alg *base = &alg->halg.base;
 
 	if (alg->halg.digestsize > PAGE_SIZE / 8 ||
-	    alg->halg.statesize > PAGE_SIZE / 8)
+	    alg->halg.statesize > PAGE_SIZE / 8 ||
+	    alg->halg.statesize == 0)
 		return -EINVAL;
 
 	base->cra_type = &crypto_ahash_type;
-- 
1.9.1

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

#1381535 — [PATCH 3.4 87/92] mvsas: Fix NULL pointer dereference in mvs_slot_task_free

From: Dāvis Mosāns <davispuh@gmail.com>

3.4.112-rc1 review patch.  If anyone has any objections, please let me know.

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


commit 2280521719e81919283b82902ac24058f87dfc1b upstream.

When pci_pool_alloc fails in mvs_task_prep then task->lldd_task stays
NULL but it's later used in mvs_abort_task as slot which is passed
to mvs_slot_task_free causing NULL pointer dereference.

Just return from mvs_slot_task_free when passed with NULL slot.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=101891
Signed-off-by: Dāvis Mosāns <davispuh@gmail.com>
Reviewed-by: Tomas Henzl <thenzl@redhat.com>
Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
Signed-off-by: James Bottomley <JBottomley@Odin.com>
Signed-off-by: Zefan Li <lizefan@huawei.com>
---
 drivers/scsi/mvsas/mv_sas.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/scsi/mvsas/mv_sas.c b/drivers/scsi/mvsas/mv_sas.c
index dbb8edf..06da698 100644
--- a/drivers/scsi/mvsas/mv_sas.c
+++ b/drivers/scsi/mvsas/mv_sas.c
@@ -984,6 +984,8 @@ static void mvs_slot_free(struct mvs_info *mvi, u32 rx_desc)
 static void mvs_slot_task_free(struct mvs_info *mvi, struct sas_task *task,
 			  struct mvs_slot_info *slot, u32 slot_idx)
 {
+	if (!slot)
+		return;
 	if (!slot->task)
 		return;
 	if (!sas_protocol_ata(task->task_proto))
-- 
1.9.1

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

#1381536 — [PATCH 3.4 86/92] dm btree: fix leak of bufio-backed block in btree_split_beneath error path

From: Mike Snitzer <snitzer@redhat.com>

3.4.112-rc1 review patch.  If anyone has any objections, please let me know.

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


commit 4dcb8b57df3593dcb20481d9d6cf79d1dc1534be upstream.

btree_split_beneath()'s error path had an outstanding FIXME that speaks
directly to the potential for _not_ cleaning up a previously allocated
bufio-backed block.

Fix this by releasing the previously allocated bufio block using
unlock_block().

Reported-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Acked-by: Joe Thornber <thornber@redhat.com>
Signed-off-by: Zefan Li <lizefan@huawei.com>
---
 drivers/md/persistent-data/dm-btree.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/md/persistent-data/dm-btree.c b/drivers/md/persistent-data/dm-btree.c
index dddd5a4..be86d59 100644
--- a/drivers/md/persistent-data/dm-btree.c
+++ b/drivers/md/persistent-data/dm-btree.c
@@ -502,7 +502,7 @@ static int btree_split_beneath(struct shadow_spine *s, uint64_t key)
 
 	r = new_block(s->info, &right);
 	if (r < 0) {
-		/* FIXME: put left */
+		unlock_block(s->info, left);
 		return r;
 	}
 
-- 
1.9.1

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

#1381537 — [PATCH 3.4 74/92] drivers/tty: require read access for controlling terminal

From: Jann Horn <jann@thejh.net>

3.4.112-rc1 review patch.  If anyone has any objections, please let me know.

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


commit 0c55627167870255158db1cde0d28366f91c8872 upstream.

This is mostly a hardening fix, given that write-only access to other
users' ttys is usually only given through setgid tty executables.

Signed-off-by: Jann Horn <jann@thejh.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[lizf: Backported to 3.4: adjust context]
Signed-off-by: Zefan Li <lizefan@huawei.com>
---
 drivers/tty/tty_io.c | 31 +++++++++++++++++++++++++++----
 1 file changed, 27 insertions(+), 4 deletions(-)

diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c
index 5f0b4a4..3ea4150 100644
--- a/drivers/tty/tty_io.c
+++ b/drivers/tty/tty_io.c
@@ -2018,8 +2018,24 @@ retry_open:
 	if (!noctty &&
 	    current->signal->leader &&
 	    !current->signal->tty &&
-	    tty->session == NULL)
-		__proc_set_tty(current, tty);
+	    tty->session == NULL) {
+		/*
+		 * Don't let a process that only has write access to the tty
+		 * obtain the privileges associated with having a tty as
+		 * controlling terminal (being able to reopen it with full
+		 * access through /dev/tty, being able to perform pushback).
+		 * Many distributions set the group of all ttys to "tty" and
+		 * grant write-only access to all terminals for setgid tty
+		 * binaries, which should not imply full privileges on all ttys.
+		 *
+		 * This could theoretically break old code that performs open()
+		 * on a write-only file descriptor. In that case, it might be
+		 * necessary to also permit this if
+		 * inode_permission(inode, MAY_READ) == 0.
+		 */
+		if (filp->f_mode & FMODE_READ)
+			__proc_set_tty(current, tty);
+	}
 	spin_unlock_irq(&current->sighand->siglock);
 	tty_unlock();
 	mutex_unlock(&tty_mutex);
@@ -2308,7 +2324,7 @@ static int fionbio(struct file *file, int __user *p)
  *		Takes ->siglock() when updating signal->tty
  */
 
-static int tiocsctty(struct tty_struct *tty, int arg)
+static int tiocsctty(struct tty_struct *tty, struct file *file, int arg)
 {
 	int ret = 0;
 	if (current->signal->leader && (task_session(current) == tty->session))
@@ -2341,6 +2357,13 @@ static int tiocsctty(struct tty_struct *tty, int arg)
 			goto unlock;
 		}
 	}
+
+	/* See the comment in tty_open(). */
+	if ((file->f_mode & FMODE_READ) == 0 && !capable(CAP_SYS_ADMIN)) {
+		ret = -EPERM;
+		goto unlock;
+	}
+
 	proc_set_tty(current, tty);
 unlock:
 	mutex_unlock(&tty_mutex);
@@ -2695,7 +2718,7 @@ long tty_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
 		no_tty();
 		return 0;
 	case TIOCSCTTY:
-		return tiocsctty(tty, arg);
+		return tiocsctty(tty, file, arg);
 	case TIOCGPGRP:
 		return tiocgpgrp(tty, real_tty, p);
 	case TIOCSPGRP:
-- 
1.9.1

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

#1381539 — [PATCH 3.4 60/92] cifs: use server timestamp for ntlmv2 authentication

From: Peter Seiderer <ps.report@gmx.net>

3.4.112-rc1 review patch.  If anyone has any objections, please let me know.

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


commit 98ce94c8df762d413b3ecb849e2b966b21606d04 upstream.

Linux cifs mount with ntlmssp against an Mac OS X (Yosemite
10.10.5) share fails in case the clocks differ more than +/-2h:

digest-service: digest-request: od failed with 2 proto=ntlmv2
digest-service: digest-request: kdc failed with -1561745592 proto=ntlmv2

Fix this by (re-)using the given server timestamp for the
ntlmv2 authentication (as Windows 7 does).

A related problem was also reported earlier by Namjae Jaen (see below):

Windows machine has extended security feature which refuse to allow
authentication when there is time difference between server time and
client time when ntlmv2 negotiation is used. This problem is prevalent
in embedded enviornment where system time is set to default 1970.

Modern servers send the server timestamp in the TargetInfo Av_Pair
structure in the challenge message [see MS-NLMP 2.2.2.1]
In [MS-NLMP 3.1.5.1.2] it is explicitly mentioned that the client must
use the server provided timestamp if present OR current time if it is
not

Reported-by: Namjae Jeon <namjae.jeon@samsung.com>
Signed-off-by: Peter Seiderer <ps.report@gmx.net>
Signed-off-by: Steve French <smfrench@gmail.com>
[lizf: Backported to 3.4: adjust context]
Signed-off-by: Zefan Li <lizefan@huawei.com>
---
 fs/cifs/cifsencrypt.c | 51 ++++++++++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 50 insertions(+), 1 deletion(-)

diff --git a/fs/cifs/cifsencrypt.c b/fs/cifs/cifsencrypt.c
index 6dd3b61..8431216 100644
--- a/fs/cifs/cifsencrypt.c
+++ b/fs/cifs/cifsencrypt.c
@@ -388,6 +388,48 @@ find_domain_name(struct cifs_ses *ses, const struct nls_table *nls_cp)
 	return 0;
 }
 
+/* Server has provided av pairs/target info in the type 2 challenge
+ * packet and we have plucked it and stored within smb session.
+ * We parse that blob here to find the server given timestamp
+ * as part of ntlmv2 authentication (or local current time as
+ * default in case of failure)
+ */
+static __le64
+find_timestamp(struct cifs_ses *ses)
+{
+	unsigned int attrsize;
+	unsigned int type;
+	unsigned int onesize = sizeof(struct ntlmssp2_name);
+	unsigned char *blobptr;
+	unsigned char *blobend;
+	struct ntlmssp2_name *attrptr;
+
+	if (!ses->auth_key.len || !ses->auth_key.response)
+		return 0;
+
+	blobptr = ses->auth_key.response;
+	blobend = blobptr + ses->auth_key.len;
+
+	while (blobptr + onesize < blobend) {
+		attrptr = (struct ntlmssp2_name *) blobptr;
+		type = le16_to_cpu(attrptr->type);
+		if (type == NTLMSSP_AV_EOL)
+			break;
+		blobptr += 2; /* advance attr type */
+		attrsize = le16_to_cpu(attrptr->length);
+		blobptr += 2; /* advance attr size */
+		if (blobptr + attrsize > blobend)
+			break;
+		if (type == NTLMSSP_AV_TIMESTAMP) {
+			if (attrsize == sizeof(u64))
+				return *((__le64 *)blobptr);
+		}
+		blobptr += attrsize; /* advance attr value */
+	}
+
+	return cpu_to_le64(cifs_UnixTimeToNT(CURRENT_TIME));
+}
+
 static int calc_ntlmv2_hash(struct cifs_ses *ses, char *ntlmv2_hash,
 			    const struct nls_table *nls_cp)
 {
@@ -549,6 +591,7 @@ setup_ntlmv2_rsp(struct cifs_ses *ses, const struct nls_table *nls_cp)
 	struct ntlmv2_resp *buf;
 	char ntlmv2_hash[16];
 	unsigned char *tiblob = NULL; /* target info blob */
+	__le64 rsp_timestamp;
 
 	if (ses->server->secType == RawNTLMSSP) {
 		if (!ses->domainName) {
@@ -566,6 +609,12 @@ setup_ntlmv2_rsp(struct cifs_ses *ses, const struct nls_table *nls_cp)
 		}
 	}
 
+	/* Must be within 5 minutes of the server (or in range +/-2h
+	 * in case of Mac OS X), so simply carry over server timestamp
+	 * (as Windows 7 does)
+	 */
+	rsp_timestamp = find_timestamp(ses);
+
 	baselen = CIFS_SESS_KEY_SIZE + sizeof(struct ntlmv2_resp);
 	tilen = ses->auth_key.len;
 	tiblob = ses->auth_key.response;
@@ -583,7 +632,7 @@ setup_ntlmv2_rsp(struct cifs_ses *ses, const struct nls_table *nls_cp)
 			(ses->auth_key.response + CIFS_SESS_KEY_SIZE);
 	buf->blob_signature = cpu_to_le32(0x00000101);
 	buf->reserved = 0;
-	buf->time = cpu_to_le64(cifs_UnixTimeToNT(CURRENT_TIME));
+	buf->time = rsp_timestamp;
 	get_random_bytes(&buf->client_chal, sizeof(buf->client_chal));
 	buf->reserved2 = 0;
 
-- 
1.9.1

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

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

Back to top | Article view | linux.kernel

csiph-web