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


Groups > linux.kernel > #1392953 > unrolled thread

[PATCH 3.14 00/37] 3.14.68-stable review

Started byGreg Kroah-Hartman <gregkh@linuxfoundation.org>
First post2016-05-03 04:00 +0200
Last post2016-05-03 17:10 +0200
Articles 20 on this page of 22 — 3 participants

Back to article view | Back to linux.kernel


Contents

  [PATCH 3.14 00/37] 3.14.68-stable review Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-05-03 04:00 +0200
    [PATCH 3.14 23/37] fbdev: da8xx-fb: fix videomodes of lcd panels Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-05-03 04:00 +0200
    [PATCH 3.14 16/37] EDAC: i7core, sb_edac: Dont return NOTIFY_BAD from mce_decoder callback Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-05-03 04:00 +0200
    [PATCH 3.14 22/37] paride: make verbose parameter an int again Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-05-03 04:00 +0200
    [PATCH 3.14 06/37] x86/iopl/64: Properly context-switch IOPL on Xen PV Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-05-03 04:00 +0200
    [PATCH 3.14 04/37] usb: hcd: out of bounds access in for_each_companion Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-05-03 04:00 +0200
    [PATCH 3.14 20/37] workqueue: fix ghost PENDING flag while doing MQ IO Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-05-03 04:00 +0200
    [PATCH 3.14 01/37] ARM: OMAP2+: hwmod: Fix updating of sysconfig register Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-05-03 04:00 +0200
    [PATCH 3.14 24/37] misc/bmp085: Enable building as a module Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-05-03 04:00 +0200
    [PATCH 3.14 02/37] assoc_array: dont call compare_object() on a node Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-05-03 04:00 +0200
    [PATCH 3.14 21/37] USB: usbip: fix potential out-of-bounds write Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-05-03 04:00 +0200
    [PATCH 3.14 05/37] lib: lz4: fixed zram with lz4 on big endian machines Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-05-03 04:00 +0200
    [PATCH 3.14 07/37] futex: Acknowledge a new waiter in counter before plist Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-05-03 04:00 +0200
    [PATCH 3.14 03/37] usb: xhci: fix wild pointers in xhci_mem_cleanup Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-05-03 04:00 +0200
    [PATCH 3.14 14/37] i2c: cpm: Fix build break due to incompatible pointer types Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-05-03 04:10 +0200
    [PATCH 3.14 15/37] i2c: exynos5: Fix possible ABBA deadlock by keeping I2C clock prepared Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-05-03 04:10 +0200
    [PATCH 3.14 12/37] Input: gtco - fix crash on detecting device without endpoints Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-05-03 04:10 +0200
    [PATCH 3.14 10/37] crypto: gcm - Fix rfc4543 decryption crash Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-05-03 04:10 +0200
    [PATCH 3.14 13/37] pinctrl: single: Fix pcs_parse_bits_in_pinctrl_entry to use __ffs than ffs Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-05-03 04:10 +0200
    Re: [PATCH 3.14 00/37] 3.14.68-stable review Guenter Roeck <linux@roeck-us.net> - 2016-05-03 09:20 +0200
      Re: [PATCH 3.14 00/37] 3.14.68-stable review Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-05-03 20:30 +0200
    Re: [PATCH 3.14 00/37] 3.14.68-stable review Shuah Khan <shuahkh@osg.samsung.com> - 2016-05-03 17:10 +0200

Page 1 of 2  [1] 2  Next page →


#1392953 — [PATCH 3.14 00/37] 3.14.68-stable review

FromGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Date2016-05-03 04:00 +0200
Subject[PATCH 3.14 00/37] 3.14.68-stable review
Message-ID<ruwee-5H5-7@gated-at.bofh.it>
This is the start of the stable review cycle for the 3.14.68 release.
There are 37 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Thu May  5 00:04:10 UTC 2016.
Anything received after that time might be too late.

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

thanks,

greg k-h

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

Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Linux 3.14.68-rc1

NeilBrown <neilb@suse.com>
    sunrpc/cache: drop reference when sunrpc_cache_pipe_upcall() detects a race

Guo-Fu Tseng <cooldavid@cooldavid.org>
    jme: Fix device PM wakeup API usage

Guo-Fu Tseng <cooldavid@cooldavid.org>
    jme: Do not enable NIC WoL functions on S0

Fabio Estevam <fabio.estevam@nxp.com>
    bus: imx-weim: Take the 'status' property value into account

Pali Rohár <pali.rohar@gmail.com>
    ARM: OMAP3: Add cpuidle parameters table for omap3430

Borislav Petkov <bp@suse.de>
    perf stat: Document --detailed option

Vitaly Kuznetsov <vkuznets@redhat.com>
    Drivers: hv: vmbus: prevent cpu offlining on newer hypervisors

Vasily Kulikov <segoon@openwall.com>
    include/linux/poison.h: fix LIST_POISON{1,2} offset

Geert Uytterhoeven <geert+renesas@glider.be>
    serial: sh-sci: Remove cpufreq notifier to fix crash/deadlock

Eryu Guan <guaneryu@gmail.com>
    ext4: fix NULL pointer dereference in ext4_mark_inode_dirty()

Michael Hennerich <michael.hennerich@analog.com>
    drivers/misc/ad525x_dpot: AD5274 fix RDAC read back errors

Geert Uytterhoeven <geert@linux-m68k.org>
    rtc: vr41xx: Wire up alarm_irq_enable

Alexander Kochetkov <al.kochet@gmail.com>
    rtc: hym8563: fix invalid year calculation

Ben Hutchings <ben@decadent.org.uk>
    misc/bmp085: Enable building as a module

Sushaanth Srirangapathi <sushaanth.s@ti.com>
    fbdev: da8xx-fb: fix videomodes of lcd panels

Arnd Bergmann <arnd@arndb.de>
    paride: make 'verbose' parameter an 'int' again

Ignat Korchagin <ignat.korchagin@gmail.com>
    USB: usbip: fix potential out-of-bounds write

Roman Pen <roman.penyaev@profitbricks.com>
    workqueue: fix ghost PENDING flag while doing MQ IO

Laszlo Ersek <lersek@redhat.com>
    efi: Fix out-of-bounds read in variable_matches()

Sugar Zhang <sugar.zhang@rock-chips.com>
    ASoC: rt5640: Correct the digital interface data select

Arnd Bergmann <arnd@arndb.de>
    ASoC: s3c24xx: use const snd_soc_component_driver pointer

Tony Luck <tony.luck@intel.com>
    EDAC: i7core, sb_edac: Don't return NOTIFY_BAD from mce_decoder callback

Javier Martinez Canillas <javier@osg.samsung.com>
    i2c: exynos5: Fix possible ABBA deadlock by keeping I2C clock prepared

Michael Ellerman <mpe@ellerman.id.au>
    i2c: cpm: Fix build break due to incompatible pointer types

Keerthy <j-keerthy@ti.com>
    pinctrl: single: Fix pcs_parse_bits_in_pinctrl_entry to use __ffs than ffs

Vladis Dronov <vdronov@redhat.com>
    Input: gtco - fix crash on detecting device without endpoints

Dmitry Ivanov <dmitrijs.ivanovs@ubnt.com>
    nl80211: check netlink protocol in socket release notification

Herbert Xu <herbert@gondor.apana.org.au>
    crypto: gcm - Fix rfc4543 decryption crash

Tom Lendacky <thomas.lendacky@amd.com>
    crypto: ccp - Prevent information leakage on export

John Keeping <john@metanate.com>
    drm/qxl: fix cursor position with non-zero hotspot

Davidlohr Bueso <dave@stgolabs.net>
    futex: Acknowledge a new waiter in counter before plist

Andy Lutomirski <luto@kernel.org>
    x86/iopl/64: Properly context-switch IOPL on Xen PV

Rui Salvaterra <rsalvaterra@gmail.com>
    lib: lz4: fixed zram with lz4 on big endian machines

Robert Dobrowolski <robert.dobrowolski@linux.intel.com>
    usb: hcd: out of bounds access in for_each_companion

Lu Baolu <baolu.lu@linux.intel.com>
    usb: xhci: fix wild pointers in xhci_mem_cleanup

Jerome Marchand <jmarchan@redhat.com>
    assoc_array: don't call compare_object() on a node

Lokesh Vutla <lokeshvutla@ti.com>
    ARM: OMAP2+: hwmod: Fix updating of sysconfig register


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

Diffstat:

 Makefile                                 |  4 +-
 arch/arm/mach-omap2/cpuidle34xx.c        | 69 +++++++++++++++++++++++++++++++-
 arch/arm/mach-omap2/omap_hwmod.c         |  8 ++--
 arch/x86/include/asm/xen/hypervisor.h    |  2 +
 arch/x86/kernel/process_64.c             | 12 ++++++
 arch/x86/xen/enlighten.c                 |  2 +-
 crypto/gcm.c                             |  3 ++
 drivers/block/paride/pd.c                |  4 +-
 drivers/block/paride/pt.c                |  4 +-
 drivers/bus/imx-weim.c                   |  2 +-
 drivers/crypto/ccp/ccp-crypto-aes-cmac.c |  3 ++
 drivers/crypto/ccp/ccp-crypto-sha.c      |  3 ++
 drivers/edac/i7core_edac.c               |  2 +-
 drivers/edac/sb_edac.c                   |  2 +-
 drivers/firmware/efi/vars.c              | 37 ++++++++++++-----
 drivers/gpu/drm/qxl/qxl_display.c        | 13 ++++--
 drivers/gpu/drm/qxl/qxl_drv.h            |  2 +
 drivers/hv/vmbus_drv.c                   | 36 +++++++++++++++++
 drivers/i2c/busses/i2c-cpm.c             |  4 +-
 drivers/i2c/busses/i2c-exynos5.c         | 24 ++++++++---
 drivers/input/tablet/gtco.c              | 10 ++++-
 drivers/misc/Kconfig                     |  2 +-
 drivers/misc/ad525x_dpot.c               |  2 +-
 drivers/net/ethernet/jme.c               | 23 ++++++-----
 drivers/pinctrl/pinctrl-single.c         |  6 +--
 drivers/rtc/rtc-hym8563.c                |  2 +-
 drivers/rtc/rtc-vr41xx.c                 | 13 +++---
 drivers/staging/usbip/usbip_common.c     | 11 +++++
 drivers/tty/serial/sh-sci.c              | 39 ------------------
 drivers/usb/core/hcd-pci.c               |  9 +++++
 drivers/usb/host/xhci-mem.c              |  6 +++
 drivers/video/da8xx-fb.c                 |  7 ++--
 fs/ext4/inode.c                          |  6 +--
 include/linux/poison.h                   |  4 +-
 kernel/futex.c                           |  2 +-
 kernel/workqueue.c                       | 29 ++++++++++++++
 lib/assoc_array.c                        |  4 +-
 lib/lz4/lz4defs.h                        | 21 +++++-----
 net/sunrpc/cache.c                       |  6 +--
 net/wireless/nl80211.c                   |  2 +-
 sound/soc/codecs/rt5640.c                |  2 +-
 sound/soc/codecs/rt5640.h                | 36 ++++++++---------
 sound/soc/samsung/s3c-i2s-v2.c           |  2 +-
 sound/soc/samsung/s3c-i2s-v2.h           |  2 +-
 tools/perf/Documentation/perf-stat.txt   |  8 ++++
 45 files changed, 346 insertions(+), 144 deletions(-)

[toc] | [next] | [standalone]


#1392954 — [PATCH 3.14 23/37] fbdev: da8xx-fb: fix videomodes of lcd panels

FromGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Date2016-05-03 04:00 +0200
Subject[PATCH 3.14 23/37] fbdev: da8xx-fb: fix videomodes of lcd panels
Message-ID<ruxN0-70R-21@gated-at.bofh.it>
In reply to#1392953
3.14-stable review patch.  If anyone has any objections, please let me know.

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

From: Sushaanth Srirangapathi <sushaanth.s@ti.com>

commit 713fced8d10fa1c759c8fb6bf9aaa681bae68cad upstream.

Commit 028cd86b794f4a ("video: da8xx-fb: fix the polarities of the
hsync/vsync pulse") fixes polarities of HSYNC/VSYNC pulse but
forgot to update known_lcd_panels[] which had sync values
according to old logic. This breaks LCD at least on DA850 EVM.

This patch fixes this issue and I have tested this for panel
"Sharp_LK043T1DG01" using DA850 EVM board.

Fixes: 028cd86b794f4a ("video: da8xx-fb: fix the polarities of the hsync/vsync pulse")
Signed-off-by: Sushaanth Srirangapathi <sushaanth.s@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/video/da8xx-fb.c |    7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

--- a/drivers/video/da8xx-fb.c
+++ b/drivers/video/da8xx-fb.c
@@ -209,8 +209,7 @@ static struct fb_videomode known_lcd_pan
 		.lower_margin   = 2,
 		.hsync_len      = 0,
 		.vsync_len      = 0,
-		.sync           = FB_SYNC_CLK_INVERT |
-			FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT,
+		.sync           = FB_SYNC_CLK_INVERT,
 	},
 	/* Sharp LK043T1DG01 */
 	[1] = {
@@ -224,7 +223,7 @@ static struct fb_videomode known_lcd_pan
 		.lower_margin   = 2,
 		.hsync_len      = 41,
 		.vsync_len      = 10,
-		.sync           = FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT,
+		.sync           = 0,
 		.flag           = 0,
 	},
 	[2] = {
@@ -239,7 +238,7 @@ static struct fb_videomode known_lcd_pan
 		.lower_margin   = 10,
 		.hsync_len      = 10,
 		.vsync_len      = 10,
-		.sync           = FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT,
+		.sync           = 0,
 		.flag           = 0,
 	},
 };

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


#1392958 — [PATCH 3.14 16/37] EDAC: i7core, sb_edac: Dont return NOTIFY_BAD from mce_decoder callback

FromGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Date2016-05-03 04:00 +0200
Subject[PATCH 3.14 16/37] EDAC: i7core, sb_edac: Dont return NOTIFY_BAD from mce_decoder callback
Message-ID<ruxN1-70R-33@gated-at.bofh.it>
In reply to#1392953
3.14-stable review patch.  If anyone has any objections, please let me know.

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

From: Tony Luck <tony.luck@intel.com>

commit c4fc1956fa31003bfbe4f597e359d751568e2954 upstream.

Both of these drivers can return NOTIFY_BAD, but this terminates
processing other callbacks that were registered later on the chain.
Since the driver did nothing to log the error it seems wrong to prevent
other interested parties from seeing it. E.g. neither of them had even
bothered to check the type of the error to see if it was a memory error
before the return NOTIFY_BAD.

Signed-off-by: Tony Luck <tony.luck@intel.com>
Acked-by: Aristeu Rozanski <aris@redhat.com>
Acked-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Cc: linux-edac <linux-edac@vger.kernel.org>
Link: http://lkml.kernel.org/r/72937355dd92318d2630979666063f8a2853495b.1461864507.git.tony.luck@intel.com
Signed-off-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/edac/i7core_edac.c |    2 +-
 drivers/edac/sb_edac.c     |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/edac/i7core_edac.c
+++ b/drivers/edac/i7core_edac.c
@@ -1878,7 +1878,7 @@ static int i7core_mce_check_error(struct
 
 	i7_dev = get_i7core_dev(mce->socketid);
 	if (!i7_dev)
-		return NOTIFY_BAD;
+		return NOTIFY_DONE;
 
 	mci = i7_dev->mci;
 	pvt = mci->pvt_info;
--- a/drivers/edac/sb_edac.c
+++ b/drivers/edac/sb_edac.c
@@ -1840,7 +1840,7 @@ static int sbridge_mce_check_error(struc
 
 	mci = get_mci_for_node_id(mce->socketid);
 	if (!mci)
-		return NOTIFY_BAD;
+		return NOTIFY_DONE;
 	pvt = mci->pvt_info;
 
 	/*

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


#1392959 — [PATCH 3.14 22/37] paride: make verbose parameter an int again

FromGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Date2016-05-03 04:00 +0200
Subject[PATCH 3.14 22/37] paride: make verbose parameter an int again
Message-ID<ruxN1-70R-31@gated-at.bofh.it>
In reply to#1392953
3.14-stable review patch.  If anyone has any objections, please let me know.

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

From: Arnd Bergmann <arnd@arndb.de>

commit dec63a4dec2d6d01346fd5d96062e67c0636852b upstream.

gcc-6.0 found an ancient bug in the paride driver, which had a
"module_param(verbose, bool, 0);" since before 2.6.12, but actually uses
it to accept '0', '1' or '2' as arguments:

  drivers/block/paride/pd.c: In function 'pd_init_dev_parms':
  drivers/block/paride/pd.c:298:29: warning: comparison of constant '1' with boolean expression is always false [-Wbool-compare]
   #define DBMSG(msg) ((verbose>1)?(msg):NULL)

In 2012, Rusty did a cleanup patch that also changed the type of the
variable to 'bool', which introduced what is now a gcc warning.

This changes the type back to 'int' and adapts the module_param() line
instead, so it should work as documented in case anyone ever cares about
running the ancient driver with debugging.

Fixes: 90ab5ee94171 ("module_param: make bool parameters really bool (drivers & misc)")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Rusty Russell <rusty@rustcorp.com.au>
Cc: Tim Waugh <tim@cyberelk.net>
Cc: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
Cc: Jens Axboe <axboe@fb.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/block/paride/pd.c |    4 ++--
 drivers/block/paride/pt.c |    4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

--- a/drivers/block/paride/pd.c
+++ b/drivers/block/paride/pd.c
@@ -126,7 +126,7 @@
 */
 #include <linux/types.h>
 
-static bool verbose = 0;
+static int verbose = 0;
 static int major = PD_MAJOR;
 static char *name = PD_NAME;
 static int cluster = 64;
@@ -161,7 +161,7 @@ enum {D_PRT, D_PRO, D_UNI, D_MOD, D_GEO,
 static DEFINE_MUTEX(pd_mutex);
 static DEFINE_SPINLOCK(pd_lock);
 
-module_param(verbose, bool, 0);
+module_param(verbose, int, 0);
 module_param(major, int, 0);
 module_param(name, charp, 0);
 module_param(cluster, int, 0);
--- a/drivers/block/paride/pt.c
+++ b/drivers/block/paride/pt.c
@@ -117,7 +117,7 @@
 
 */
 
-static bool verbose = 0;
+static int verbose = 0;
 static int major = PT_MAJOR;
 static char *name = PT_NAME;
 static int disable = 0;
@@ -152,7 +152,7 @@ static int (*drives[4])[6] = {&drive0, &
 
 #include <asm/uaccess.h>
 
-module_param(verbose, bool, 0);
+module_param(verbose, int, 0);
 module_param(major, int, 0);
 module_param(name, charp, 0);
 module_param_array(drive0, int, NULL, 0);

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


#1392961 — [PATCH 3.14 06/37] x86/iopl/64: Properly context-switch IOPL on Xen PV

FromGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Date2016-05-03 04:00 +0200
Subject[PATCH 3.14 06/37] x86/iopl/64: Properly context-switch IOPL on Xen PV
Message-ID<ruxN1-70R-35@gated-at.bofh.it>
In reply to#1392953
3.14-stable review patch.  If anyone has any objections, please let me know.

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

From: Andy Lutomirski <luto@kernel.org>

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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 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(-)

--- a/arch/x86/include/asm/xen/hypervisor.h
+++ b/arch/x86/include/asm/xen/hypervisor.h
@@ -57,4 +57,6 @@ static inline bool xen_x2apic_para_avail
 }
 #endif
 
+extern void xen_set_iopl_mask(unsigned mask);
+
 #endif /* _ASM_X86_XEN_HYPERVISOR_H */
--- 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);
 
@@ -427,6 +428,17 @@ __switch_to(struct task_struct *prev_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;
 }
 
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -956,7 +956,7 @@ static void xen_load_sp0(struct tss_stru
 	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;
 

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


#1392962 — [PATCH 3.14 04/37] usb: hcd: out of bounds access in for_each_companion

FromGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Date2016-05-03 04:00 +0200
Subject[PATCH 3.14 04/37] usb: hcd: out of bounds access in for_each_companion
Message-ID<ruxN1-70R-47@gated-at.bofh.it>
In reply to#1392953
3.14-stable review patch.  If anyone has any objections, please let me know.

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

From: Robert Dobrowolski <robert.dobrowolski@linux.intel.com>

commit e86103a75705c7c530768f4ffaba74cf382910f2 upstream.

On BXT platform Host Controller and Device Controller figure as
same PCI device but with different device function. HCD should
not pass data to Device Controller but only to Host Controllers.
Checking if companion device is Host Controller, otherwise skip.

Signed-off-by: Robert Dobrowolski <robert.dobrowolski@linux.intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/usb/core/hcd-pci.c |    9 +++++++++
 1 file changed, 9 insertions(+)

--- a/drivers/usb/core/hcd-pci.c
+++ b/drivers/usb/core/hcd-pci.c
@@ -74,6 +74,15 @@ static void for_each_companion(struct pc
 		if (companion->bus != pdev->bus ||
 				PCI_SLOT(companion->devfn) != slot)
 			continue;
+
+		/*
+		 * Companion device should be either UHCI,OHCI or EHCI host
+		 * controller, otherwise skip.
+		 */
+		if (companion->class != CL_UHCI && companion->class != CL_OHCI &&
+				companion->class != CL_EHCI)
+			continue;
+
 		companion_hcd = pci_get_drvdata(companion);
 		if (!companion_hcd || !companion_hcd->self.root_hub)
 			continue;

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


#1392966 — [PATCH 3.14 20/37] workqueue: fix ghost PENDING flag while doing MQ IO

FromGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Date2016-05-03 04:00 +0200
Subject[PATCH 3.14 20/37] workqueue: fix ghost PENDING flag while doing MQ IO
Message-ID<ruxN1-70R-45@gated-at.bofh.it>
In reply to#1392953
3.14-stable review patch.  If anyone has any objections, please let me know.

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

From: Roman Pen <roman.penyaev@profitbricks.com>

commit 346c09f80459a3ad97df1816d6d606169a51001a upstream.

The bug in a workqueue leads to a stalled IO request in MQ ctx->rq_list
with the following backtrace:

[  601.347452] INFO: task kworker/u129:5:1636 blocked for more than 120 seconds.
[  601.347574]       Tainted: G           O    4.4.5-1-storage+ #6
[  601.347651] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[  601.348142] kworker/u129:5  D ffff880803077988     0  1636      2 0x00000000
[  601.348519] Workqueue: ibnbd_server_fileio_wq ibnbd_dev_file_submit_io_worker [ibnbd_server]
[  601.348999]  ffff880803077988 ffff88080466b900 ffff8808033f9c80 ffff880803078000
[  601.349662]  ffff880807c95000 7fffffffffffffff ffffffff815b0920 ffff880803077ad0
[  601.350333]  ffff8808030779a0 ffffffff815b01d5 0000000000000000 ffff880803077a38
[  601.350965] Call Trace:
[  601.351203]  [<ffffffff815b0920>] ? bit_wait+0x60/0x60
[  601.351444]  [<ffffffff815b01d5>] schedule+0x35/0x80
[  601.351709]  [<ffffffff815b2dd2>] schedule_timeout+0x192/0x230
[  601.351958]  [<ffffffff812d43f7>] ? blk_flush_plug_list+0xc7/0x220
[  601.352208]  [<ffffffff810bd737>] ? ktime_get+0x37/0xa0
[  601.352446]  [<ffffffff815b0920>] ? bit_wait+0x60/0x60
[  601.352688]  [<ffffffff815af784>] io_schedule_timeout+0xa4/0x110
[  601.352951]  [<ffffffff815b3a4e>] ? _raw_spin_unlock_irqrestore+0xe/0x10
[  601.353196]  [<ffffffff815b093b>] bit_wait_io+0x1b/0x70
[  601.353440]  [<ffffffff815b056d>] __wait_on_bit+0x5d/0x90
[  601.353689]  [<ffffffff81127bd0>] wait_on_page_bit+0xc0/0xd0
[  601.353958]  [<ffffffff81096db0>] ? autoremove_wake_function+0x40/0x40
[  601.354200]  [<ffffffff81127cc4>] __filemap_fdatawait_range+0xe4/0x140
[  601.354441]  [<ffffffff81127d34>] filemap_fdatawait_range+0x14/0x30
[  601.354688]  [<ffffffff81129a9f>] filemap_write_and_wait_range+0x3f/0x70
[  601.354932]  [<ffffffff811ced3b>] blkdev_fsync+0x1b/0x50
[  601.355193]  [<ffffffff811c82d9>] vfs_fsync_range+0x49/0xa0
[  601.355432]  [<ffffffff811cf45a>] blkdev_write_iter+0xca/0x100
[  601.355679]  [<ffffffff81197b1a>] __vfs_write+0xaa/0xe0
[  601.355925]  [<ffffffff81198379>] vfs_write+0xa9/0x1a0
[  601.356164]  [<ffffffff811c59d8>] kernel_write+0x38/0x50

The underlying device is a null_blk, with default parameters:

  queue_mode    = MQ
  submit_queues = 1

Verification that nullb0 has something inflight:

root@pserver8:~# cat /sys/block/nullb0/inflight
       0        1
root@pserver8:~# find /sys/block/nullb0/mq/0/cpu* -name rq_list -print -exec cat {} \;
...
/sys/block/nullb0/mq/0/cpu2/rq_list
CTX pending:
        ffff8838038e2400
...

During debug it became clear that stalled request is always inserted in
the rq_list from the following path:

   save_stack_trace_tsk + 34
   blk_mq_insert_requests + 231
   blk_mq_flush_plug_list + 281
   blk_flush_plug_list + 199
   wait_on_page_bit + 192
   __filemap_fdatawait_range + 228
   filemap_fdatawait_range + 20
   filemap_write_and_wait_range + 63
   blkdev_fsync + 27
   vfs_fsync_range + 73
   blkdev_write_iter + 202
   __vfs_write + 170
   vfs_write + 169
   kernel_write + 56

So blk_flush_plug_list() was called with from_schedule == true.

If from_schedule is true, that means that finally blk_mq_insert_requests()
offloads execution of __blk_mq_run_hw_queue() and uses kblockd workqueue,
i.e. it calls kblockd_schedule_delayed_work_on().

That means, that we race with another CPU, which is about to execute
__blk_mq_run_hw_queue() work.

Further debugging shows the following traces from different CPUs:

  CPU#0                                  CPU#1
  ----------------------------------     -------------------------------
  reqeust A inserted
  STORE hctx->ctx_map[0] bit marked
  kblockd_schedule...() returns 1
  <schedule to kblockd workqueue>
                                         request B inserted
                                         STORE hctx->ctx_map[1] bit marked
                                         kblockd_schedule...() returns 0
  *** WORK PENDING bit is cleared ***
  flush_busy_ctxs() is executed, but
  bit 1, set by CPU#1, is not observed

As a result request B pended forever.

This behaviour can be explained by speculative LOAD of hctx->ctx_map on
CPU#0, which is reordered with clear of PENDING bit and executed _before_
actual STORE of bit 1 on CPU#1.

The proper fix is an explicit full barrier <mfence>, which guarantees
that clear of PENDING bit is to be executed before all possible
speculative LOADS or STORES inside actual work function.

Signed-off-by: Roman Pen <roman.penyaev@profitbricks.com>
Cc: Gioh Kim <gi-oh.kim@profitbricks.com>
Cc: Michael Wang <yun.wang@profitbricks.com>
Cc: Tejun Heo <tj@kernel.org>
Cc: Jens Axboe <axboe@kernel.dk>
Cc: linux-block@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -629,6 +629,35 @@ static void set_work_pool_and_clear_pend
 	 */
 	smp_wmb();
 	set_work_data(work, (unsigned long)pool_id << WORK_OFFQ_POOL_SHIFT, 0);
+	/*
+	 * The following mb guarantees that previous clear of a PENDING bit
+	 * will not be reordered with any speculative LOADS or STORES from
+	 * work->current_func, which is executed afterwards.  This possible
+	 * reordering can lead to a missed execution on attempt to qeueue
+	 * the same @work.  E.g. consider this case:
+	 *
+	 *   CPU#0                         CPU#1
+	 *   ----------------------------  --------------------------------
+	 *
+	 * 1  STORE event_indicated
+	 * 2  queue_work_on() {
+	 * 3    test_and_set_bit(PENDING)
+	 * 4 }                             set_..._and_clear_pending() {
+	 * 5                                 set_work_data() # clear bit
+	 * 6                                 smp_mb()
+	 * 7                               work->current_func() {
+	 * 8				      LOAD event_indicated
+	 *				   }
+	 *
+	 * Without an explicit full barrier speculative LOAD on line 8 can
+	 * be executed before CPU#0 does STORE on line 1.  If that happens,
+	 * CPU#0 observes the PENDING bit is still set and new execution of
+	 * a @work is not queued in a hope, that CPU#1 will eventually
+	 * finish the queued @work.  Meanwhile CPU#1 does not see
+	 * event_indicated is set, because speculative LOAD was executed
+	 * before actual STORE.
+	 */
+	smp_mb();
 }
 
 static void clear_work_data(struct work_struct *work)

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


#1392970 — [PATCH 3.14 01/37] ARM: OMAP2+: hwmod: Fix updating of sysconfig register

FromGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Date2016-05-03 04:00 +0200
Subject[PATCH 3.14 01/37] ARM: OMAP2+: hwmod: Fix updating of sysconfig register
Message-ID<ruxN2-70R-55@gated-at.bofh.it>
In reply to#1392953
3.14-stable review patch.  If anyone has any objections, please let me know.

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

From: Lokesh Vutla <lokeshvutla@ti.com>

commit 3ca4a238106dedc285193ee47f494a6584b6fd2f upstream.

Commit 127500ccb766f ("ARM: OMAP2+: Only write the sysconfig on idle
when necessary") talks about verification of sysconfig cache value before
updating it, only during idle path. But the patch is adding the
verification in the enable path. So, adding the check in a proper place
as per the commit description.

Not keeping this check during enable path as there is a chance of losing
context and it is safe to do on idle as the context of the register will
never be lost while the device is active.

Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Acked-by: Tero Kristo <t-kristo@ti.com>
Cc: Jon Hunter <jonathanh@nvidia.com>
Fixes: commit 127500ccb766 "ARM: OMAP2+: Only write the sysconfig on idle when necessary"
[paul@pwsan.com: appears to have been caused by my own mismerge of the
 originally posted patch]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 arch/arm/mach-omap2/omap_hwmod.c |    8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -1439,9 +1439,7 @@ static void _enable_sysc(struct omap_hwm
 	    (sf & SYSC_HAS_CLOCKACTIVITY))
 		_set_clockactivity(oh, oh->class->sysc->clockact, &v);
 
-	/* If the cached value is the same as the new value, skip the write */
-	if (oh->_sysc_cache != v)
-		_write_sysconfig(v, oh);
+	_write_sysconfig(v, oh);
 
 	/*
 	 * Set the autoidle bit only after setting the smartidle bit
@@ -1504,7 +1502,9 @@ static void _idle_sysc(struct omap_hwmod
 		_set_master_standbymode(oh, idlemode, &v);
 	}
 
-	_write_sysconfig(v, oh);
+	/* If the cached value is the same as the new value, skip the write */
+	if (oh->_sysc_cache != v)
+		_write_sysconfig(v, oh);
 }
 
 /**

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


#1392972 — [PATCH 3.14 24/37] misc/bmp085: Enable building as a module

FromGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Date2016-05-03 04:00 +0200
Subject[PATCH 3.14 24/37] misc/bmp085: Enable building as a module
Message-ID<ruxN2-70R-57@gated-at.bofh.it>
In reply to#1392953
3.14-stable review patch.  If anyone has any objections, please let me know.

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

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

commit 50e6315dba721cbc24ccd6d7b299f1782f210a98 upstream.

Commit 985087dbcb02 'misc: add support for bmp18x chips to the bmp085
driver' changed the BMP085 config symbol to a boolean.  I see no
reason why the shared code cannot be built as a module, so change it
back to tristate.

Fixes: 985087dbcb02 ("misc: add support for bmp18x chips to the bmp085 driver")
Cc: Eric Andersson <eric.andersson@unixphere.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/misc/Kconfig |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -438,7 +438,7 @@ config ARM_CHARLCD
 	  still useful.
 
 config BMP085
-	bool
+	tristate
 	depends on SYSFS
 
 config BMP085_I2C

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


#1392973 — [PATCH 3.14 02/37] assoc_array: dont call compare_object() on a node

FromGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Date2016-05-03 04:00 +0200
Subject[PATCH 3.14 02/37] assoc_array: dont call compare_object() on a node
Message-ID<ruxN3-70R-61@gated-at.bofh.it>
In reply to#1392953
3.14-stable review patch.  If anyone has any objections, please let me know.

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

From: Jerome Marchand <jmarchan@redhat.com>

commit 8d4a2ec1e0b41b0cf9a0c5cd4511da7f8e4f3de2 upstream.

Changes since V1: fixed the description and added KASan warning.

In assoc_array_insert_into_terminal_node(), we call the
compare_object() method on all non-empty slots, even when they're
not leaves, passing a pointer to an unexpected structure to
compare_object(). Currently it causes an out-of-bound read access
in keyring_compare_object detected by KASan (see below). The issue
is easily reproduced with keyutils testsuite.
Only call compare_object() when the slot is a leave.

KASan warning:
==================================================================
BUG: KASAN: slab-out-of-bounds in keyring_compare_object+0x213/0x240 at addr ffff880060a6f838
Read of size 8 by task keyctl/1655
=============================================================================
BUG kmalloc-192 (Not tainted): kasan: bad access detected
-----------------------------------------------------------------------------

Disabling lock debugging due to kernel taint
INFO: Allocated in assoc_array_insert+0xfd0/0x3a60 age=69 cpu=1 pid=1647
	___slab_alloc+0x563/0x5c0
	__slab_alloc+0x51/0x90
	kmem_cache_alloc_trace+0x263/0x300
	assoc_array_insert+0xfd0/0x3a60
	__key_link_begin+0xfc/0x270
	key_create_or_update+0x459/0xaf0
	SyS_add_key+0x1ba/0x350
	entry_SYSCALL_64_fastpath+0x12/0x76
INFO: Slab 0xffffea0001829b80 objects=16 used=8 fp=0xffff880060a6f550 flags=0x3fff8000004080
INFO: Object 0xffff880060a6f740 @offset=5952 fp=0xffff880060a6e5d1

Bytes b4 ffff880060a6f730: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Object ffff880060a6f740: d1 e5 a6 60 00 88 ff ff 0e 00 00 00 00 00 00 00  ...`............
Object ffff880060a6f750: 02 cf 8e 60 00 88 ff ff 02 c0 8e 60 00 88 ff ff  ...`.......`....
Object ffff880060a6f760: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Object ffff880060a6f770: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Object ffff880060a6f780: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Object ffff880060a6f790: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Object ffff880060a6f7a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Object ffff880060a6f7b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Object ffff880060a6f7c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Object ffff880060a6f7d0: 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Object ffff880060a6f7e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Object ffff880060a6f7f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
CPU: 0 PID: 1655 Comm: keyctl Tainted: G    B           4.5.0-rc4-kasan+ #291
Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
 0000000000000000 000000001b2800b4 ffff880060a179e0 ffffffff81b60491
 ffff88006c802900 ffff880060a6f740 ffff880060a17a10 ffffffff815e2969
 ffff88006c802900 ffffea0001829b80 ffff880060a6f740 ffff880060a6e650
Call Trace:
 [<ffffffff81b60491>] dump_stack+0x85/0xc4
 [<ffffffff815e2969>] print_trailer+0xf9/0x150
 [<ffffffff815e9454>] object_err+0x34/0x40
 [<ffffffff815ebe50>] kasan_report_error+0x230/0x550
 [<ffffffff819949be>] ? keyring_get_key_chunk+0x13e/0x210
 [<ffffffff815ec62d>] __asan_report_load_n_noabort+0x5d/0x70
 [<ffffffff81994cc3>] ? keyring_compare_object+0x213/0x240
 [<ffffffff81994cc3>] keyring_compare_object+0x213/0x240
 [<ffffffff81bc238c>] assoc_array_insert+0x86c/0x3a60
 [<ffffffff81bc1b20>] ? assoc_array_cancel_edit+0x70/0x70
 [<ffffffff8199797d>] ? __key_link_begin+0x20d/0x270
 [<ffffffff8199786c>] __key_link_begin+0xfc/0x270
 [<ffffffff81993389>] key_create_or_update+0x459/0xaf0
 [<ffffffff8128ce0d>] ? trace_hardirqs_on+0xd/0x10
 [<ffffffff81992f30>] ? key_type_lookup+0xc0/0xc0
 [<ffffffff8199e19d>] ? lookup_user_key+0x13d/0xcd0
 [<ffffffff81534763>] ? memdup_user+0x53/0x80
 [<ffffffff819983ea>] SyS_add_key+0x1ba/0x350
 [<ffffffff81998230>] ? key_get_type_from_user.constprop.6+0xa0/0xa0
 [<ffffffff828bcf4e>] ? retint_user+0x18/0x23
 [<ffffffff8128cc7e>] ? trace_hardirqs_on_caller+0x3fe/0x580
 [<ffffffff81004017>] ? trace_hardirqs_on_thunk+0x17/0x19
 [<ffffffff828bc432>] entry_SYSCALL_64_fastpath+0x12/0x76
Memory state around the buggy address:
 ffff880060a6f700: fc fc fc fc fc fc fc fc 00 00 00 00 00 00 00 00
 ffff880060a6f780: 00 00 00 00 00 00 00 00 00 00 00 fc fc fc fc fc
>ffff880060a6f800: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
                                        ^
 ffff880060a6f880: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
 ffff880060a6f900: fc fc fc fc fc fc 00 00 00 00 00 00 00 00 00 00
==================================================================

Signed-off-by: Jerome Marchand <jmarchan@redhat.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 lib/assoc_array.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

--- a/lib/assoc_array.c
+++ b/lib/assoc_array.c
@@ -523,7 +523,9 @@ static bool assoc_array_insert_into_term
 			free_slot = i;
 			continue;
 		}
-		if (ops->compare_object(assoc_array_ptr_to_leaf(ptr), index_key)) {
+		if (assoc_array_ptr_is_leaf(ptr) &&
+		    ops->compare_object(assoc_array_ptr_to_leaf(ptr),
+					index_key)) {
 			pr_devel("replace in slot %d\n", i);
 			edit->leaf_p = &node->slots[i];
 			edit->dead_leaf = node->slots[i];

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


#1392974 — [PATCH 3.14 21/37] USB: usbip: fix potential out-of-bounds write

FromGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Date2016-05-03 04:00 +0200
Subject[PATCH 3.14 21/37] USB: usbip: fix potential out-of-bounds write
Message-ID<ruxN3-70R-63@gated-at.bofh.it>
In reply to#1392953
3.14-stable review patch.  If anyone has any objections, please let me know.

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

From: Ignat Korchagin <ignat.korchagin@gmail.com>

commit b348d7dddb6c4fbfc810b7a0626e8ec9e29f7cbb upstream.

Fix potential out-of-bounds write to urb->transfer_buffer
usbip handles network communication directly in the kernel. When receiving a
packet from its peer, usbip code parses headers according to protocol. As
part of this parsing urb->actual_length is filled. Since the input for
urb->actual_length comes from the network, it should be treated as untrusted.
Any entity controlling the network may put any value in the input and the
preallocated urb->transfer_buffer may not be large enough to hold the data.
Thus, the malicious entity is able to write arbitrary data to kernel memory.

Signed-off-by: Ignat Korchagin <ignat.korchagin@gmail.com>
Cc: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/staging/usbip/usbip_common.c |   11 +++++++++++
 1 file changed, 11 insertions(+)

--- a/drivers/staging/usbip/usbip_common.c
+++ b/drivers/staging/usbip/usbip_common.c
@@ -785,6 +785,17 @@ int usbip_recv_xbuff(struct usbip_device
 	if (!(size > 0))
 		return 0;
 
+	if (size > urb->transfer_buffer_length) {
+		/* should not happen, probably malicious packet */
+		if (ud->side == USBIP_STUB) {
+			usbip_event_add(ud, SDEV_EVENT_ERROR_TCP);
+			return 0;
+		} else {
+			usbip_event_add(ud, VDEV_EVENT_ERROR_TCP);
+			return -EPIPE;
+		}
+	}
+
 	ret = usbip_recv(ud->tcp_socket, urb->transfer_buffer, size);
 	if (ret != size) {
 		dev_err(&urb->dev->dev, "recv xbuf, %d\n", ret);

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


#1392975 — [PATCH 3.14 05/37] lib: lz4: fixed zram with lz4 on big endian machines

FromGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Date2016-05-03 04:00 +0200
Subject[PATCH 3.14 05/37] lib: lz4: fixed zram with lz4 on big endian machines
Message-ID<ruxN3-70R-65@gated-at.bofh.it>
In reply to#1392953
3.14-stable review patch.  If anyone has any objections, please let me know.

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

From: Rui Salvaterra <rsalvaterra@gmail.com>

commit 3e26a691fe3fe1e02a76e5bab0c143ace4b137b4 upstream.

Based on Sergey's test patch [1], this fixes zram with lz4 compression
on big endian cpus.

Note that the 64-bit preprocessor test is not a cleanup, it's part of
the fix, since those identifiers are bogus (for example, __ppc64__
isn't defined anywhere else in the kernel, which means we'd fall into
the 32-bit definitions on ppc64).

Tested on ppc64 with no regression on x86_64.

[1] http://marc.info/?l=linux-kernel&m=145994470805853&w=4

Suggested-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Signed-off-by: Rui Salvaterra <rsalvaterra@gmail.com>
Reviewed-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 lib/lz4/lz4defs.h |   21 ++++++++++++---------
 1 file changed, 12 insertions(+), 9 deletions(-)

--- a/lib/lz4/lz4defs.h
+++ b/lib/lz4/lz4defs.h
@@ -11,8 +11,7 @@
 /*
  * Detects 64 bits mode
  */
-#if (defined(__x86_64__) || defined(__x86_64) || defined(__amd64__) \
-	|| defined(__ppc64__) || defined(__LP64__))
+#if defined(CONFIG_64BIT)
 #define LZ4_ARCH64 1
 #else
 #define LZ4_ARCH64 0
@@ -35,6 +34,10 @@ typedef struct _U64_S { u64 v; } U64_S;
 
 #define PUT4(s, d) (A32(d) = A32(s))
 #define PUT8(s, d) (A64(d) = A64(s))
+
+#define LZ4_READ_LITTLEENDIAN_16(d, s, p)	\
+	(d = s - A16(p))
+
 #define LZ4_WRITE_LITTLEENDIAN_16(p, v)	\
 	do {	\
 		A16(p) = v; \
@@ -51,10 +54,13 @@ typedef struct _U64_S { u64 v; } U64_S;
 #define PUT8(s, d) \
 	put_unaligned(get_unaligned((const u64 *) s), (u64 *) d)
 
-#define LZ4_WRITE_LITTLEENDIAN_16(p, v)	\
-	do {	\
-		put_unaligned(v, (u16 *)(p)); \
-		p += 2; \
+#define LZ4_READ_LITTLEENDIAN_16(d, s, p)	\
+	(d = s - get_unaligned_le16(p))
+
+#define LZ4_WRITE_LITTLEENDIAN_16(p, v)			\
+	do {						\
+		put_unaligned_le16(v, (u16 *)(p));	\
+		p += 2;					\
 	} while (0)
 #endif
 
@@ -140,9 +146,6 @@ typedef struct _U64_S { u64 v; } U64_S;
 
 #endif
 
-#define LZ4_READ_LITTLEENDIAN_16(d, s, p) \
-	(d = s - get_unaligned_le16(p))
-
 #define LZ4_WILDCOPY(s, d, e)		\
 	do {				\
 		LZ4_COPYPACKET(s, d);	\

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


#1392977 — [PATCH 3.14 07/37] futex: Acknowledge a new waiter in counter before plist

FromGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Date2016-05-03 04:00 +0200
Subject[PATCH 3.14 07/37] futex: Acknowledge a new waiter in counter before plist
Message-ID<ruxN3-70R-69@gated-at.bofh.it>
In reply to#1392953
3.14-stable review patch.  If anyone has any objections, please let me know.

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

From: Davidlohr Bueso <dave@stgolabs.net>

commit fe1bce9e2107ba3a8faffe572483b6974201a0e6 upstream.

Otherwise an incoming waker on the dest hash bucket can miss
the waiter adding itself to the plist during the lockless
check optimization (small window but still the correct way
of doing this); similarly to the decrement counterpart.

Suggested-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Davidlohr Bueso <dbueso@suse.de>
Cc: Davidlohr Bueso <dave@stgolabs.net>
Cc: bigeasy@linutronix.de
Cc: dvhart@infradead.org
Link: http://lkml.kernel.org/r/1461208164-29150-1-git-send-email-dave@stgolabs.net
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -1378,8 +1378,8 @@ void requeue_futex(struct futex_q *q, st
 	if (likely(&hb1->chain != &hb2->chain)) {
 		plist_del(&q->list, &hb1->chain);
 		hb_waiters_dec(hb1);
-		plist_add(&q->list, &hb2->chain);
 		hb_waiters_inc(hb2);
+		plist_add(&q->list, &hb2->chain);
 		q->lock_ptr = &hb2->lock;
 	}
 	get_futex_key_refs(key2);

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


#1392980 — [PATCH 3.14 03/37] usb: xhci: fix wild pointers in xhci_mem_cleanup

FromGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Date2016-05-03 04:00 +0200
Subject[PATCH 3.14 03/37] usb: xhci: fix wild pointers in xhci_mem_cleanup
Message-ID<ruxN4-70R-75@gated-at.bofh.it>
In reply to#1392953
3.14-stable review patch.  If anyone has any objections, please let me know.

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

From: Lu Baolu <baolu.lu@linux.intel.com>

commit 71504062a7c34838c3fccd92c447f399d3cb5797 upstream.

This patch fixes some wild pointers produced by xhci_mem_cleanup.
These wild pointers will cause system crash if xhci_mem_cleanup()
is called twice.

Reported-and-tested-by: Pengcheng Li <lpc.li@hisilicon.com>
Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/usb/host/xhci-mem.c |    6 ++++++
 1 file changed, 6 insertions(+)

--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -1785,6 +1785,12 @@ no_bw:
 	kfree(xhci->rh_bw);
 	kfree(xhci->ext_caps);
 
+	xhci->usb2_ports = NULL;
+	xhci->usb3_ports = NULL;
+	xhci->port_array = NULL;
+	xhci->rh_bw = NULL;
+	xhci->ext_caps = NULL;
+
 	xhci->page_size = 0;
 	xhci->page_shift = 0;
 	xhci->bus_state[0].bus_suspended = 0;

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


#1392982 — [PATCH 3.14 14/37] i2c: cpm: Fix build break due to incompatible pointer types

FromGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Date2016-05-03 04:10 +0200
Subject[PATCH 3.14 14/37] i2c: cpm: Fix build break due to incompatible pointer types
Message-ID<ruxWG-7p8-3@gated-at.bofh.it>
In reply to#1392953
3.14-stable review patch.  If anyone has any objections, please let me know.

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

From: Michael Ellerman <mpe@ellerman.id.au>

commit 609d5a1b2b35bb62b4b3750396e55453160c2a17 upstream.

Since commit ea8daa7b9784 ("kbuild: Add option to turn incompatible
pointer check into error"), assignments from an incompatible pointer
types have become a hard error, eg:

  drivers/i2c/busses/i2c-cpm.c:545:91: error: passing argument 3 of
  'dma_alloc_coherent' from incompatible pointer type

Fix the build break by converting txdma & rxdma to dma_addr_t.

Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Fixes: ea8daa7b9784
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/i2c/busses/i2c-cpm.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/i2c/busses/i2c-cpm.c
+++ b/drivers/i2c/busses/i2c-cpm.c
@@ -120,8 +120,8 @@ struct cpm_i2c {
 	cbd_t __iomem *rbase;
 	u_char *txbuf[CPM_MAXBD];
 	u_char *rxbuf[CPM_MAXBD];
-	u32 txdma[CPM_MAXBD];
-	u32 rxdma[CPM_MAXBD];
+	dma_addr_t txdma[CPM_MAXBD];
+	dma_addr_t rxdma[CPM_MAXBD];
 };
 
 static irqreturn_t cpm_i2c_interrupt(int irq, void *dev_id)

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


#1392983 — [PATCH 3.14 15/37] i2c: exynos5: Fix possible ABBA deadlock by keeping I2C clock prepared

FromGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Date2016-05-03 04:10 +0200
Subject[PATCH 3.14 15/37] i2c: exynos5: Fix possible ABBA deadlock by keeping I2C clock prepared
Message-ID<ruxWG-7p8-5@gated-at.bofh.it>
In reply to#1392953
3.14-stable review patch.  If anyone has any objections, please let me know.

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

From: Javier Martinez Canillas <javier@osg.samsung.com>

commit 10ff4c5239a137abfc896ec73ef3d15a0f86a16a upstream.

The exynos5 I2C controller driver always prepares and enables a clock
before using it and then disables unprepares it when the clock is not
used anymore.

But this can cause a possible ABBA deadlock in some scenarios since a
driver that uses regmap to access its I2C registers, will first grab
the regmap lock and then the I2C xfer function will grab the prepare
lock when preparing the I2C clock. But since the clock driver also
uses regmap for I2C accesses, preparing a clock will first grab the
prepare lock and then the regmap lock when using the regmap API.

An example of this happens on the Exynos5422 Odroid XU4 board where a
s2mps11 PMIC is used and both the s2mps11 regulators and clk drivers
share the same I2C regmap.

The possible deadlock is reported by the kernel lockdep:

  Possible unsafe locking scenario:

        CPU0                    CPU1
        ----                    ----
   lock(sec_core:428:(regmap)->lock);
                                lock(prepare_lock);
                                lock(sec_core:428:(regmap)->lock);
   lock(prepare_lock);

  *** DEADLOCK ***

Fix it by leaving the code prepared on probe and use {en,dis}able in
the I2C transfer function.

This patch is similar to commit 34e81ad5f0b6 ("i2c: s3c2410: fix ABBA
deadlock by keeping clock prepared") that fixes the same bug in other
driver for an I2C controller found in Samsung SoCs.

Reported-by: Anand Moon <linux.amoon@gmail.com>
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Reviewed-by: Anand Moon <linux.amoon@gmail.com>
Reviewed-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/i2c/busses/i2c-exynos5.c |   24 +++++++++++++++++++-----
 1 file changed, 19 insertions(+), 5 deletions(-)

--- a/drivers/i2c/busses/i2c-exynos5.c
+++ b/drivers/i2c/busses/i2c-exynos5.c
@@ -574,7 +574,9 @@ static int exynos5_i2c_xfer(struct i2c_a
 		return -EIO;
 	}
 
-	clk_prepare_enable(i2c->clk);
+	ret = clk_enable(i2c->clk);
+	if (ret)
+		return ret;
 
 	for (i = 0; i < num; i++, msgs++) {
 		stop = (i == num - 1);
@@ -598,7 +600,7 @@ static int exynos5_i2c_xfer(struct i2c_a
 	}
 
  out:
-	clk_disable_unprepare(i2c->clk);
+	clk_disable(i2c->clk);
 	return ret;
 }
 
@@ -652,7 +654,9 @@ static int exynos5_i2c_probe(struct plat
 		return -ENOENT;
 	}
 
-	clk_prepare_enable(i2c->clk);
+	ret = clk_prepare_enable(i2c->clk);
+	if (ret)
+		return ret;
 
 	mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 	i2c->regs = devm_ioremap_resource(&pdev->dev, mem);
@@ -701,6 +705,10 @@ static int exynos5_i2c_probe(struct plat
 
 	platform_set_drvdata(pdev, i2c);
 
+	clk_disable(i2c->clk);
+
+	return 0;
+
  err_clk:
 	clk_disable_unprepare(i2c->clk);
 	return ret;
@@ -712,6 +720,8 @@ static int exynos5_i2c_remove(struct pla
 
 	i2c_del_adapter(&i2c->adap);
 
+	clk_unprepare(i2c->clk);
+
 	return 0;
 }
 
@@ -722,6 +732,8 @@ static int exynos5_i2c_suspend_noirq(str
 
 	i2c->suspended = 1;
 
+	clk_unprepare(i2c->clk);
+
 	return 0;
 }
 
@@ -731,7 +743,9 @@ static int exynos5_i2c_resume_noirq(stru
 	struct exynos5_i2c *i2c = platform_get_drvdata(pdev);
 	int ret = 0;
 
-	clk_prepare_enable(i2c->clk);
+	ret = clk_prepare_enable(i2c->clk);
+	if (ret)
+		return ret;
 
 	ret = exynos5_hsi2c_clock_setup(i2c);
 	if (ret) {
@@ -740,7 +754,7 @@ static int exynos5_i2c_resume_noirq(stru
 	}
 
 	exynos5_i2c_init(i2c);
-	clk_disable_unprepare(i2c->clk);
+	clk_disable(i2c->clk);
 	i2c->suspended = 0;
 
 	return 0;

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


#1392984 — [PATCH 3.14 12/37] Input: gtco - fix crash on detecting device without endpoints

FromGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Date2016-05-03 04:10 +0200
Subject[PATCH 3.14 12/37] Input: gtco - fix crash on detecting device without endpoints
Message-ID<ruxWG-7p8-7@gated-at.bofh.it>
In reply to#1392953
3.14-stable review patch.  If anyone has any objections, please let me know.

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

From: Vladis Dronov <vdronov@redhat.com>

commit 162f98dea487206d9ab79fc12ed64700667a894d upstream.

The gtco driver expects at least one valid endpoint. If given malicious
descriptors that specify 0 for the number of endpoints, it will crash in
the probe function. Ensure there is at least one endpoint on the interface
before using it.

Also let's fix a minor coding style issue.

The full correct report of this issue can be found in the public
Red Hat Bugzilla:

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

Reported-by: Ralf Spenneberg <ralf@spenneberg.net>
Signed-off-by: Vladis Dronov <vdronov@redhat.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/input/tablet/gtco.c |   10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

--- a/drivers/input/tablet/gtco.c
+++ b/drivers/input/tablet/gtco.c
@@ -868,6 +868,14 @@ static int gtco_probe(struct usb_interfa
 		goto err_free_buf;
 	}
 
+	/* Sanity check that a device has an endpoint */
+	if (usbinterface->altsetting[0].desc.bNumEndpoints < 1) {
+		dev_err(&usbinterface->dev,
+			"Invalid number of endpoints\n");
+		error = -EINVAL;
+		goto err_free_urb;
+	}
+
 	/*
 	 * The endpoint is always altsetting 0, we know this since we know
 	 * this device only has one interrupt endpoint
@@ -889,7 +897,7 @@ static int gtco_probe(struct usb_interfa
 	 * HID report descriptor
 	 */
 	if (usb_get_extra_descriptor(usbinterface->cur_altsetting,
-				     HID_DEVICE_TYPE, &hid_desc) != 0){
+				     HID_DEVICE_TYPE, &hid_desc) != 0) {
 		dev_err(&usbinterface->dev,
 			"Can't retrieve exta USB descriptor to get hid report descriptor length\n");
 		error = -EIO;

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


#1392985 — [PATCH 3.14 10/37] crypto: gcm - Fix rfc4543 decryption crash

FromGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Date2016-05-03 04:10 +0200
Subject[PATCH 3.14 10/37] crypto: gcm - Fix rfc4543 decryption crash
Message-ID<ruxWG-7p8-9@gated-at.bofh.it>
In reply to#1392953
3.14-stable review patch.  If anyone has any objections, please let me know.

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

From: Herbert Xu <herbert@gondor.apana.org.au>

This bug has already bee fixed upstream since 4.2.  However, it
was fixed during the AEAD conversion so no fix was backported to
the older kernels.

When we do an RFC 4543 decryption, we will end up writing the
ICV beyond the end of the dst buffer.  This should lead to a
crash but for some reason it was never noticed.

This patch fixes it by only writing back the ICV for encryption.

Fixes: d733ac90f9fe ("crypto: gcm - fix rfc4543 to handle async...")
Reported-by: Patrick Meyer <patrick.meyer@vasgard.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 crypto/gcm.c |    3 +++
 1 file changed, 3 insertions(+)

--- a/crypto/gcm.c
+++ b/crypto/gcm.c
@@ -1173,6 +1173,9 @@ static struct aead_request *crypto_rfc45
 	aead_request_set_tfm(subreq, ctx->child);
 	aead_request_set_callback(subreq, req->base.flags, crypto_rfc4543_done,
 				  req);
+	if (!enc)
+		aead_request_set_callback(subreq, req->base.flags,
+					  req->base.complete, req->base.data);
 	aead_request_set_crypt(subreq, cipher, cipher, enc ? 0 : authsize, iv);
 	aead_request_set_assoc(subreq, assoc, assoclen);
 

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


#1392987 — [PATCH 3.14 13/37] pinctrl: single: Fix pcs_parse_bits_in_pinctrl_entry to use __ffs than ffs

FromGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Date2016-05-03 04:10 +0200
Subject[PATCH 3.14 13/37] pinctrl: single: Fix pcs_parse_bits_in_pinctrl_entry to use __ffs than ffs
Message-ID<ruxWG-7p8-11@gated-at.bofh.it>
In reply to#1392953
3.14-stable review patch.  If anyone has any objections, please let me know.

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

From: Keerthy <j-keerthy@ti.com>

commit 56b367c0cd67d4c3006738e7dc9dda9273fd2bfe upstream.

pcs_parse_bits_in_pinctrl_entry uses ffs which gives bit indices
ranging from 1 to MAX. This leads to a corner case where we try to request
the pin number = MAX and fails.

bit_pos value is being calculted using ffs. pin_num_from_lsb uses
bit_pos value. pins array is populated with:

pin + pin_num_from_lsb.

The above is 1 more than usual bit indices as bit_pos uses ffs to compute
first set bit. Hence the last of the pins array is populated with the MAX
value and not MAX - 1 which causes error when we call pin_request.

mask_pos is rightly calculated as ((pcs->fmask) << (bit_pos - 1))
Consequently val_pos and submask are correct.

Hence use __ffs which gives (ffs(x) - 1) as the first bit set.

fixes: 4e7e8017a8 ("pinctrl: pinctrl-single: enhance to configure multiple pins of different modules")
Signed-off-by: Keerthy <j-keerthy@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/pinctrl/pinctrl-single.c |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

--- a/drivers/pinctrl/pinctrl-single.c
+++ b/drivers/pinctrl/pinctrl-single.c
@@ -1313,9 +1313,9 @@ static int pcs_parse_bits_in_pinctrl_ent
 
 		/* Parse pins in each row from LSB */
 		while (mask) {
-			bit_pos = ffs(mask);
+			bit_pos = __ffs(mask);
 			pin_num_from_lsb = bit_pos / pcs->bits_per_pin;
-			mask_pos = ((pcs->fmask) << (bit_pos - 1));
+			mask_pos = ((pcs->fmask) << bit_pos);
 			val_pos = val & mask_pos;
 			submask = mask & mask_pos;
 
@@ -1892,7 +1892,7 @@ static int pcs_probe(struct platform_dev
 	ret = of_property_read_u32(np, "pinctrl-single,function-mask",
 				   &pcs->fmask);
 	if (!ret) {
-		pcs->fshift = ffs(pcs->fmask) - 1;
+		pcs->fshift = __ffs(pcs->fmask);
 		pcs->fmax = pcs->fmask >> pcs->fshift;
 	} else {
 		/* If mask property doesn't exist, function mux is invalid. */

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


#1393100

FromGuenter Roeck <linux@roeck-us.net>
Date2016-05-03 09:20 +0200
Message-ID<ruCMF-3wS-7@gated-at.bofh.it>
In reply to#1392953
On 05/02/2016 05:11 PM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.14.68 release.
> There are 37 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Thu May  5 00:04:10 UTC 2016.
> Anything received after that time might be too late.
>

Build results:
	total: 129 pass: 129 fail: 0
Qemu test results:
	total: 89 pass: 89 fail: 0

Details are available at http://kerneltests.org/builders.

Guenter

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


Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.kernel


csiph-web