--- /dev/null
+From 0b938a2e2cf0b0a2c8bac9769111545aff0fee97 Mon Sep 17 00:00:00 2001
+From: John Johansen <john.johansen@canonical.com>
+Date: Wed, 18 Nov 2015 11:41:05 -0800
+Subject: apparmor: fix ref count leak when profile sha1 hash is read
+
+From: John Johansen <john.johansen@canonical.com>
+
+commit 0b938a2e2cf0b0a2c8bac9769111545aff0fee97 upstream.
+
+Signed-off-by: John Johansen <john.johansen@canonical.com>
+Acked-by: Seth Arnold <seth.arnold@canonical.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ security/apparmor/apparmorfs.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/security/apparmor/apparmorfs.c
++++ b/security/apparmor/apparmorfs.c
+@@ -331,6 +331,7 @@ static int aa_fs_seq_hash_show(struct se
+ seq_printf(seq, "%.2x", profile->hash[i]);
+ seq_puts(seq, "\n");
+ }
++ aa_put_profile(profile);
+
+ return 0;
+ }
--- /dev/null
+From 7de249964f5578e67b99699c5f0b405738d820a2 Mon Sep 17 00:00:00 2001
+From: Dave Weinstein <olorin@google.com>
+Date: Thu, 28 Jul 2016 11:55:41 -0700
+Subject: arm: oabi compat: add missing access checks
+
+From: Dave Weinstein <olorin@google.com>
+
+commit 7de249964f5578e67b99699c5f0b405738d820a2 upstream.
+
+Add access checks to sys_oabi_epoll_wait() and sys_oabi_semtimedop().
+This fixes CVE-2016-3857, a local privilege escalation under
+CONFIG_OABI_COMPAT.
+
+Reported-by: Chiachih Wu <wuchiachih@gmail.com>
+Reviewed-by: Kees Cook <keescook@chromium.org>
+Reviewed-by: Nicolas Pitre <nico@linaro.org>
+Signed-off-by: Dave Weinstein <olorin@google.com>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/arm/kernel/sys_oabi-compat.c | 8 +++++++-
+ 1 file changed, 7 insertions(+), 1 deletion(-)
+
+--- a/arch/arm/kernel/sys_oabi-compat.c
++++ b/arch/arm/kernel/sys_oabi-compat.c
+@@ -279,8 +279,12 @@ asmlinkage long sys_oabi_epoll_wait(int
+ mm_segment_t fs;
+ long ret, err, i;
+
+- if (maxevents <= 0 || maxevents > (INT_MAX/sizeof(struct epoll_event)))
++ if (maxevents <= 0 ||
++ maxevents > (INT_MAX/sizeof(*kbuf)) ||
++ maxevents > (INT_MAX/sizeof(*events)))
+ return -EINVAL;
++ if (!access_ok(VERIFY_WRITE, events, sizeof(*events) * maxevents))
++ return -EFAULT;
+ kbuf = kmalloc(sizeof(*kbuf) * maxevents, GFP_KERNEL);
+ if (!kbuf)
+ return -ENOMEM;
+@@ -317,6 +321,8 @@ asmlinkage long sys_oabi_semtimedop(int
+
+ if (nsops < 1 || nsops > SEMOPM)
+ return -EINVAL;
++ if (!access_ok(VERIFY_READ, tsops, sizeof(*tsops) * nsops))
++ return -EFAULT;
+ sops = kmalloc(sizeof(*sops) * nsops, GFP_KERNEL);
+ if (!sops)
+ return -ENOMEM;
--- /dev/null
+From 4d06dd537f95683aba3651098ae288b7cbff8274 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Bj=C3=B8rn=20Mork?= <bjorn@mork.no>
+Date: Mon, 7 Mar 2016 21:15:36 +0100
+Subject: cdc_ncm: do not call usbnet_link_change from cdc_ncm_bind
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Bjørn Mork <bjorn@mork.no>
+
+commit 4d06dd537f95683aba3651098ae288b7cbff8274 upstream.
+
+usbnet_link_change will call schedule_work and should be
+avoided if bind is failing. Otherwise we will end up with
+scheduled work referring to a netdev which has gone away.
+
+Instead of making the call conditional, we can just defer
+it to usbnet_probe, using the driver_info flag made for
+this purpose.
+
+Fixes: 8a34b0ae8778 ("usbnet: cdc_ncm: apply usbnet_link_change")
+Reported-by: Andrey Konovalov <andreyknvl@gmail.com>
+Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Bjørn Mork <bjorn@mork.no>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/net/usb/cdc_ncm.c | 20 +++++---------------
+ 1 file changed, 5 insertions(+), 15 deletions(-)
+
+--- a/drivers/net/usb/cdc_ncm.c
++++ b/drivers/net/usb/cdc_ncm.c
+@@ -952,8 +952,6 @@ EXPORT_SYMBOL_GPL(cdc_ncm_select_altsett
+
+ static int cdc_ncm_bind(struct usbnet *dev, struct usb_interface *intf)
+ {
+- int ret;
+-
+ /* MBIM backwards compatible function? */
+ if (cdc_ncm_select_altsetting(intf) != CDC_NCM_COMM_ALTSETTING_NCM)
+ return -ENODEV;
+@@ -962,16 +960,7 @@ static int cdc_ncm_bind(struct usbnet *d
+ * Additionally, generic NCM devices are assumed to accept arbitrarily
+ * placed NDP.
+ */
+- ret = cdc_ncm_bind_common(dev, intf, CDC_NCM_DATA_ALTSETTING_NCM, 0);
+-
+- /*
+- * We should get an event when network connection is "connected" or
+- * "disconnected". Set network connection in "disconnected" state
+- * (carrier is OFF) during attach, so the IP network stack does not
+- * start IPv6 negotiation and more.
+- */
+- usbnet_link_change(dev, 0, 0);
+- return ret;
++ return cdc_ncm_bind_common(dev, intf, CDC_NCM_DATA_ALTSETTING_NCM, 0);
+ }
+
+ static void cdc_ncm_align_tail(struct sk_buff *skb, size_t modulus, size_t remainder, size_t max)
+@@ -1554,7 +1543,8 @@ static void cdc_ncm_status(struct usbnet
+
+ static const struct driver_info cdc_ncm_info = {
+ .description = "CDC NCM",
+- .flags = FLAG_POINTTOPOINT | FLAG_NO_SETINT | FLAG_MULTI_PACKET,
++ .flags = FLAG_POINTTOPOINT | FLAG_NO_SETINT | FLAG_MULTI_PACKET
++ | FLAG_LINK_INTR,
+ .bind = cdc_ncm_bind,
+ .unbind = cdc_ncm_unbind,
+ .manage_power = usbnet_manage_power,
+@@ -1567,7 +1557,7 @@ static const struct driver_info cdc_ncm_
+ static const struct driver_info wwan_info = {
+ .description = "Mobile Broadband Network Device",
+ .flags = FLAG_POINTTOPOINT | FLAG_NO_SETINT | FLAG_MULTI_PACKET
+- | FLAG_WWAN,
++ | FLAG_LINK_INTR | FLAG_WWAN,
+ .bind = cdc_ncm_bind,
+ .unbind = cdc_ncm_unbind,
+ .manage_power = usbnet_manage_power,
+@@ -1580,7 +1570,7 @@ static const struct driver_info wwan_inf
+ static const struct driver_info wwan_noarp_info = {
+ .description = "Mobile Broadband Network Device (NO ARP)",
+ .flags = FLAG_POINTTOPOINT | FLAG_NO_SETINT | FLAG_MULTI_PACKET
+- | FLAG_WWAN | FLAG_NOARP,
++ | FLAG_LINK_INTR | FLAG_WWAN | FLAG_NOARP,
+ .bind = cdc_ncm_bind,
+ .unbind = cdc_ncm_unbind,
+ .manage_power = usbnet_manage_power,
--- /dev/null
+From 67245ff332064c01b760afa7a384ccda024bfd24 Mon Sep 17 00:00:00 2001
+From: Linus Torvalds <torvalds@linux-foundation.org>
+Date: Sat, 16 Apr 2016 15:16:07 -0700
+Subject: devpts: clean up interface to pty drivers
+
+From: Linus Torvalds <torvalds@linux-foundation.org>
+
+commit 67245ff332064c01b760afa7a384ccda024bfd24 upstream.
+
+This gets rid of the horrible notion of having that
+
+ struct inode *ptmx_inode
+
+be the linchpin of the interface between the pty code and devpts.
+
+By de-emphasizing the ptmx inode, a lot of things actually get cleaner,
+and we will have a much saner way forward. In particular, this will
+allow us to associate with any particular devpts instance at open-time,
+and not be artificially tied to one particular ptmx inode.
+
+The patch itself is actually fairly straightforward, and apart from some
+locking and return path cleanups it's pretty mechanical:
+
+ - the interfaces that devpts exposes all take "struct pts_fs_info *"
+ instead of "struct inode *ptmx_inode" now.
+
+ NOTE! The "struct pts_fs_info" thing is a completely opaque structure
+ as far as the pty driver is concerned: it's still declared entirely
+ internally to devpts. So the pty code can't actually access it in any
+ way, just pass it as a "cookie" to the devpts code.
+
+ - the "look up the pts fs info" is now a single clear operation, that
+ also does the reference count increment on the pts superblock.
+
+ So "devpts_add/del_ref()" is gone, and replaced by a "lookup and get
+ ref" operation (devpts_get_ref(inode)), along with a "put ref" op
+ (devpts_put_ref()).
+
+ - the pty master "tty->driver_data" field now contains the pts_fs_info,
+ not the ptmx inode.
+
+ - because we don't care about the ptmx inode any more as some kind of
+ base index, the ref counting can now drop the inode games - it just
+ gets the ref on the superblock.
+
+ - the pts_fs_info now has a back-pointer to the super_block. That's so
+ that we can easily look up the information we actually need. Although
+ quite often, the pts fs info was actually all we wanted, and not having
+ to look it up based on some magical inode makes things more
+ straightforward.
+
+In particular, now that "devpts_get_ref(inode)" operation should really
+be the *only* place we need to look up what devpts instance we're
+associated with, and we do it exactly once, at ptmx_open() time.
+
+The other side of this is that one ptmx node could now be associated
+with multiple different devpts instances - you could have a single
+/dev/ptmx node, and then have multiple mount namespaces with their own
+instances of devpts mounted on /dev/pts/. And that's all perfectly sane
+in a model where we just look up the pts instance at open time.
+
+This will eventually allow us to get rid of our odd single-vs-multiple
+pts instance model, but this patch in itself changes no semantics, only
+an internal binding model.
+
+Cc: Eric Biederman <ebiederm@xmission.com>
+Cc: Peter Anvin <hpa@zytor.com>
+Cc: Andy Lutomirski <luto@amacapital.net>
+Cc: Al Viro <viro@zeniv.linux.org.uk>
+Cc: Peter Hurley <peter@hurleysoftware.com>
+Cc: Serge Hallyn <serge.hallyn@ubuntu.com>
+Cc: Willy Tarreau <w@1wt.eu>
+Cc: Aurelien Jarno <aurelien@aurel32.net>
+Cc: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
+Cc: Jann Horn <jann@thejh.net>
+Cc: Greg KH <greg@kroah.com>
+Cc: Jiri Slaby <jslaby@suse.com>
+Cc: Florian Weimer <fw@deneb.enyo.de>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Cc: Francesco Ruggeri <fruggeri@arista.com>
+Cc: "Herton R. Krzesinski" <herton@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/tty/pty.c | 63 +++++++++++++++++++++-------------------------
+ fs/devpts/inode.c | 49 +++++++++++++++++------------------
+ include/linux/devpts_fs.h | 34 +++++++-----------------
+ 3 files changed, 64 insertions(+), 82 deletions(-)
+
+--- a/drivers/tty/pty.c
++++ b/drivers/tty/pty.c
+@@ -679,14 +679,14 @@ static void pty_unix98_remove(struct tty
+ /* this is called once with whichever end is closed last */
+ static void pty_unix98_shutdown(struct tty_struct *tty)
+ {
+- struct inode *ptmx_inode;
++ struct pts_fs_info *fsi;
+
+ if (tty->driver->subtype == PTY_TYPE_MASTER)
+- ptmx_inode = tty->driver_data;
++ fsi = tty->driver_data;
+ else
+- ptmx_inode = tty->link->driver_data;
+- devpts_kill_index(ptmx_inode, tty->index);
+- devpts_del_ref(ptmx_inode);
++ fsi = tty->link->driver_data;
++ devpts_kill_index(fsi, tty->index);
++ devpts_put_ref(fsi);
+ }
+
+ static const struct tty_operations ptm_unix98_ops = {
+@@ -738,6 +738,7 @@ static const struct tty_operations pty_u
+
+ static int ptmx_open(struct inode *inode, struct file *filp)
+ {
++ struct pts_fs_info *fsi;
+ struct tty_struct *tty;
+ struct inode *slave_inode;
+ int retval;
+@@ -752,47 +753,41 @@ static int ptmx_open(struct inode *inode
+ if (retval)
+ return retval;
+
++ fsi = devpts_get_ref(inode, filp);
++ retval = -ENODEV;
++ if (!fsi)
++ goto out_free_file;
++
+ /* find a device that is not in use. */
+ mutex_lock(&devpts_mutex);
+- index = devpts_new_index(inode);
+- if (index < 0) {
+- retval = index;
+- mutex_unlock(&devpts_mutex);
+- goto err_file;
+- }
+-
++ index = devpts_new_index(fsi);
+ mutex_unlock(&devpts_mutex);
+
+- mutex_lock(&tty_mutex);
+- tty = tty_init_dev(ptm_driver, index);
++ retval = index;
++ if (index < 0)
++ goto out_put_ref;
+
+- if (IS_ERR(tty)) {
+- retval = PTR_ERR(tty);
+- goto out;
+- }
+
++ mutex_lock(&tty_mutex);
++ tty = tty_init_dev(ptm_driver, index);
+ /* The tty returned here is locked so we can safely
+ drop the mutex */
+ mutex_unlock(&tty_mutex);
+
+- set_bit(TTY_PTY_LOCK, &tty->flags); /* LOCK THE SLAVE */
+- tty->driver_data = inode;
++ retval = PTR_ERR(tty);
++ if (IS_ERR(tty))
++ goto out;
+
+ /*
+- * In the case where all references to ptmx inode are dropped and we
+- * still have /dev/tty opened pointing to the master/slave pair (ptmx
+- * is closed/released before /dev/tty), we must make sure that the inode
+- * is still valid when we call the final pty_unix98_shutdown, thus we
+- * hold an additional reference to the ptmx inode. For the same /dev/tty
+- * last close case, we also need to make sure the super_block isn't
+- * destroyed (devpts instance unmounted), before /dev/tty is closed and
+- * on its release devpts_kill_index is called.
++ * From here on out, the tty is "live", and the index and
++ * fsi will be killed/put by the tty_release()
+ */
+- devpts_add_ref(inode);
++ set_bit(TTY_PTY_LOCK, &tty->flags); /* LOCK THE SLAVE */
++ tty->driver_data = fsi;
+
+ tty_add_file(tty, filp);
+
+- slave_inode = devpts_pty_new(inode,
++ slave_inode = devpts_pty_new(fsi,
+ MKDEV(UNIX98_PTY_SLAVE_MAJOR, index), index,
+ tty->link);
+ if (IS_ERR(slave_inode)) {
+@@ -811,12 +806,14 @@ static int ptmx_open(struct inode *inode
+ return 0;
+ err_release:
+ tty_unlock(tty);
++ // This will also put-ref the fsi
+ tty_release(inode, filp);
+ return retval;
+ out:
+- mutex_unlock(&tty_mutex);
+- devpts_kill_index(inode, index);
+-err_file:
++ devpts_kill_index(fsi, index);
++out_put_ref:
++ devpts_put_ref(fsi);
++out_free_file:
+ tty_free_file(filp);
+ return retval;
+ }
+--- a/fs/devpts/inode.c
++++ b/fs/devpts/inode.c
+@@ -128,6 +128,7 @@ static const match_table_t tokens = {
+ struct pts_fs_info {
+ struct ida allocated_ptys;
+ struct pts_mount_opts mount_opts;
++ struct super_block *sb;
+ struct dentry *ptmx_dentry;
+ };
+
+@@ -358,7 +359,7 @@ static const struct super_operations dev
+ .show_options = devpts_show_options,
+ };
+
+-static void *new_pts_fs_info(void)
++static void *new_pts_fs_info(struct super_block *sb)
+ {
+ struct pts_fs_info *fsi;
+
+@@ -369,6 +370,7 @@ static void *new_pts_fs_info(void)
+ ida_init(&fsi->allocated_ptys);
+ fsi->mount_opts.mode = DEVPTS_DEFAULT_MODE;
+ fsi->mount_opts.ptmxmode = DEVPTS_DEFAULT_PTMX_MODE;
++ fsi->sb = sb;
+
+ return fsi;
+ }
+@@ -384,7 +386,7 @@ devpts_fill_super(struct super_block *s,
+ s->s_op = &devpts_sops;
+ s->s_time_gran = 1;
+
+- s->s_fs_info = new_pts_fs_info();
++ s->s_fs_info = new_pts_fs_info(s);
+ if (!s->s_fs_info)
+ goto fail;
+
+@@ -524,17 +526,14 @@ static struct file_system_type devpts_fs
+ * to the System V naming convention
+ */
+
+-int devpts_new_index(struct inode *ptmx_inode)
++int devpts_new_index(struct pts_fs_info *fsi)
+ {
+- struct super_block *sb = pts_sb_from_inode(ptmx_inode);
+- struct pts_fs_info *fsi;
+ int index;
+ int ida_ret;
+
+- if (!sb)
++ if (!fsi)
+ return -ENODEV;
+
+- fsi = DEVPTS_SB(sb);
+ retry:
+ if (!ida_pre_get(&fsi->allocated_ptys, GFP_KERNEL))
+ return -ENOMEM;
+@@ -564,11 +563,8 @@ retry:
+ return index;
+ }
+
+-void devpts_kill_index(struct inode *ptmx_inode, int idx)
++void devpts_kill_index(struct pts_fs_info *fsi, int idx)
+ {
+- struct super_block *sb = pts_sb_from_inode(ptmx_inode);
+- struct pts_fs_info *fsi = DEVPTS_SB(sb);
+-
+ mutex_lock(&allocated_ptys_lock);
+ ida_remove(&fsi->allocated_ptys, idx);
+ pty_count--;
+@@ -578,21 +574,25 @@ void devpts_kill_index(struct inode *ptm
+ /*
+ * pty code needs to hold extra references in case of last /dev/tty close
+ */
+-
+-void devpts_add_ref(struct inode *ptmx_inode)
++struct pts_fs_info *devpts_get_ref(struct inode *ptmx_inode, struct file *file)
+ {
+- struct super_block *sb = pts_sb_from_inode(ptmx_inode);
++ struct super_block *sb;
++ struct pts_fs_info *fsi;
++
++ sb = pts_sb_from_inode(ptmx_inode);
++ if (!sb)
++ return NULL;
++ fsi = DEVPTS_SB(sb);
++ if (!fsi)
++ return NULL;
+
+ atomic_inc(&sb->s_active);
+- ihold(ptmx_inode);
++ return fsi;
+ }
+
+-void devpts_del_ref(struct inode *ptmx_inode)
++void devpts_put_ref(struct pts_fs_info *fsi)
+ {
+- struct super_block *sb = pts_sb_from_inode(ptmx_inode);
+-
+- iput(ptmx_inode);
+- deactivate_super(sb);
++ deactivate_super(fsi->sb);
+ }
+
+ /**
+@@ -604,22 +604,21 @@ void devpts_del_ref(struct inode *ptmx_i
+ *
+ * The created inode is returned. Remove it from /dev/pts/ by devpts_pty_kill.
+ */
+-struct inode *devpts_pty_new(struct inode *ptmx_inode, dev_t device, int index,
++struct inode *devpts_pty_new(struct pts_fs_info *fsi, dev_t device, int index,
+ void *priv)
+ {
+ struct dentry *dentry;
+- struct super_block *sb = pts_sb_from_inode(ptmx_inode);
++ struct super_block *sb;
+ struct inode *inode;
+ struct dentry *root;
+- struct pts_fs_info *fsi;
+ struct pts_mount_opts *opts;
+ char s[12];
+
+- if (!sb)
++ if (!fsi)
+ return ERR_PTR(-ENODEV);
+
++ sb = fsi->sb;
+ root = sb->s_root;
+- fsi = DEVPTS_SB(sb);
+ opts = &fsi->mount_opts;
+
+ inode = new_inode(sb);
+--- a/include/linux/devpts_fs.h
++++ b/include/linux/devpts_fs.h
+@@ -15,38 +15,24 @@
+
+ #include <linux/errno.h>
+
++struct pts_fs_info;
++
+ #ifdef CONFIG_UNIX98_PTYS
+
+-int devpts_new_index(struct inode *ptmx_inode);
+-void devpts_kill_index(struct inode *ptmx_inode, int idx);
+-void devpts_add_ref(struct inode *ptmx_inode);
+-void devpts_del_ref(struct inode *ptmx_inode);
++/* Look up a pts fs info and get a ref to it */
++struct pts_fs_info *devpts_get_ref(struct inode *, struct file *);
++void devpts_put_ref(struct pts_fs_info *);
++
++int devpts_new_index(struct pts_fs_info *);
++void devpts_kill_index(struct pts_fs_info *, int);
++
+ /* mknod in devpts */
+-struct inode *devpts_pty_new(struct inode *ptmx_inode, dev_t device, int index,
+- void *priv);
++struct inode *devpts_pty_new(struct pts_fs_info *, dev_t, int, void *);
+ /* get private structure */
+ void *devpts_get_priv(struct inode *pts_inode);
+ /* unlink */
+ void devpts_pty_kill(struct inode *inode);
+
+-#else
+-
+-/* Dummy stubs in the no-pty case */
+-static inline int devpts_new_index(struct inode *ptmx_inode) { return -EINVAL; }
+-static inline void devpts_kill_index(struct inode *ptmx_inode, int idx) { }
+-static inline void devpts_add_ref(struct inode *ptmx_inode) { }
+-static inline void devpts_del_ref(struct inode *ptmx_inode) { }
+-static inline struct inode *devpts_pty_new(struct inode *ptmx_inode,
+- dev_t device, int index, void *priv)
+-{
+- return ERR_PTR(-EINVAL);
+-}
+-static inline void *devpts_get_priv(struct inode *pts_inode)
+-{
+- return NULL;
+-}
+-static inline void devpts_pty_kill(struct inode *inode) { }
+-
+ #endif
+
+
--- /dev/null
+From e2e407dc093f530b771ee8bf8fe1be41e3cea8b3 Mon Sep 17 00:00:00 2001
+From: Matt Roper <matthew.d.roper@intel.com>
+Date: Mon, 8 Feb 2016 11:05:28 -0800
+Subject: drm/i915: Pretend cursor is always on for ILK-style WM calculations (v2)
+
+From: Matt Roper <matthew.d.roper@intel.com>
+
+commit e2e407dc093f530b771ee8bf8fe1be41e3cea8b3 upstream.
+
+Due to our lack of two-step watermark programming, our driver has
+historically pretended that the cursor plane is always on for the
+purpose of watermark calculations; this helps avoid serious flickering
+when the cursor turns off/on (e.g., when the user moves the mouse
+pointer to a different screen). That workaround was accidentally
+dropped as we started working toward atomic watermark updates. Since we
+still aren't quite there yet with two-stage updates, we need to
+resurrect the workaround and treat the cursor as always active.
+
+v2: Tweak cursor width calculations slightly to more closely match the
+ logic we used before the atomic overhaul began. (Ville)
+
+Cc: simdev11@outlook.com
+Cc: manfred.kitzbichler@gmail.com
+Cc: drm-intel-fixes@lists.freedesktop.org
+Reported-by: simdev11@outlook.com
+Reported-by: manfred.kitzbichler@gmail.com
+Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93892
+Fixes: 43d59eda1 ("drm/i915: Eliminate usage of plane_wm_parameters from ILK-style WM code (v2)")
+Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
+Link: http://patchwork.freedesktop.org/patch/msgid/1454479611-6804-1-git-send-email-matthew.d.roper@intel.com
+(cherry picked from commit b2435692dbb709d4c8ff3b2f2815c9b8423b72bb)
+Signed-off-by: Jani Nikula <jani.nikula@intel.com>
+Link: http://patchwork.freedesktop.org/patch/msgid/1454958328-30129-1-git-send-email-matthew.d.roper@intel.com
+Tested-by: Jay <mymailclone@t-online.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/i915/intel_pm.c | 14 +++++++++-----
+ 1 file changed, 9 insertions(+), 5 deletions(-)
+
+--- a/drivers/gpu/drm/i915/intel_pm.c
++++ b/drivers/gpu/drm/i915/intel_pm.c
+@@ -1789,16 +1789,20 @@ static uint32_t ilk_compute_cur_wm(const
+ const struct intel_plane_state *pstate,
+ uint32_t mem_value)
+ {
+- int bpp = pstate->base.fb ? pstate->base.fb->bits_per_pixel / 8 : 0;
++ /*
++ * We treat the cursor plane as always-on for the purposes of watermark
++ * calculation. Until we have two-stage watermark programming merged,
++ * this is necessary to avoid flickering.
++ */
++ int cpp = 4;
++ int width = pstate->visible ? pstate->base.crtc_w : 64;
+
+- if (!cstate->base.active || !pstate->visible)
++ if (!cstate->base.active)
+ return 0;
+
+ return ilk_wm_method2(ilk_pipe_pixel_rate(cstate),
+ cstate->base.adjusted_mode.crtc_htotal,
+- drm_rect_width(&pstate->dst),
+- bpp,
+- mem_value);
++ width, cpp, mem_value);
+ }
+
+ /* Only for WM_LP. */
--- /dev/null
+From 19f4c2ba869517048add62c202f9645b6adf5dfb Mon Sep 17 00:00:00 2001
+From: Benjamin Tissoires <benjamin.tissoires@redhat.com>
+Date: Fri, 8 Jan 2016 17:58:49 +0100
+Subject: HID: sony: do not bail out when the sixaxis refuses the output report
+
+From: Benjamin Tissoires <benjamin.tissoires@redhat.com>
+
+commit 19f4c2ba869517048add62c202f9645b6adf5dfb upstream.
+
+When setting the operational mode, some third party (Speedlink Strike-FX)
+gamepads refuse the output report. Failing here means we refuse to
+initialize the gamepad while this should be harmless.
+
+The weird part is that the initial commit that added this: a7de9b8
+("HID: sony: Enable Gasia third-party PS3 controllers") mentions this
+very same controller as one requiring this output report.
+Anyway, it's broken for one user at least, so let's change it.
+We will report an error, but at least the controller should work.
+
+And no, these devices present themselves as legacy Sony controllers
+(VID:PID of 054C:0268, as in the official ones) so there are no ways
+of discriminating them from the official ones.
+
+https://bugzilla.redhat.com/show_bug.cgi?id=1255325
+
+Reported-and-tested-by: Max Fedotov <thesourcehim@gmail.com>
+Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
+Signed-off-by: Jiri Kosina <jkosina@suse.cz>
+Cc: Laura Abbott <labbott@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/hid/hid-sony.c | 6 ++++--
+ 1 file changed, 4 insertions(+), 2 deletions(-)
+
+--- a/drivers/hid/hid-sony.c
++++ b/drivers/hid/hid-sony.c
+@@ -1418,8 +1418,10 @@ static int sixaxis_set_operational_usb(s
+ }
+
+ ret = hid_hw_output_report(hdev, buf, 1);
+- if (ret < 0)
+- hid_err(hdev, "can't set operational mode: step 3\n");
++ if (ret < 0) {
++ hid_info(hdev, "can't set operational mode: step 3, ignoring\n");
++ ret = 0;
++ }
+
+ out:
+ kfree(buf);
--- /dev/null
+From a7ae81952cdab56a1277bd2f9ed7284c0f575120 Mon Sep 17 00:00:00 2001
+From: Mika Westerberg <mika.westerberg@linux.intel.com>
+Date: Thu, 9 Jun 2016 16:56:28 +0300
+Subject: i2c: i801: Allow ACPI SystemIO OpRegion to conflict with PCI BAR
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Mika Westerberg <mika.westerberg@linux.intel.com>
+
+commit a7ae81952cdab56a1277bd2f9ed7284c0f575120 upstream.
+
+Many Intel systems the BIOS declares a SystemIO OpRegion below the SMBus
+PCI device as can be seen in ACPI DSDT table from Lenovo Yoga 900:
+
+ Device (SBUS)
+ {
+ OperationRegion (SMBI, SystemIO, (SBAR << 0x05), 0x10)
+ Field (SMBI, ByteAcc, NoLock, Preserve)
+ {
+ HSTS, 8,
+ Offset (0x02),
+ HCON, 8,
+ HCOM, 8,
+ TXSA, 8,
+ DAT0, 8,
+ DAT1, 8,
+ HBDR, 8,
+ PECR, 8,
+ RXSA, 8,
+ SDAT, 16
+ }
+
+There are also bunch of AML methods that that the BIOS can use to access
+these fields. Most of the systems in question AML methods accessing the
+SMBI OpRegion are never used.
+
+Now, because of this SMBI OpRegion many systems fail to load the SMBus
+driver with an error looking like one below:
+
+ ACPI Warning: SystemIO range 0x0000000000003040-0x000000000000305F
+ conflicts with OpRegion 0x0000000000003040-0x000000000000304F
+ (\_SB.PCI0.SBUS.SMBI) (20160108/utaddress-255)
+ ACPI: If an ACPI driver is available for this device, you should use
+ it instead of the native driver
+
+The reason is that this SMBI OpRegion conflicts with the PCI BAR used by
+the SMBus driver.
+
+It turns out that we can install a custom SystemIO address space handler
+for the SMBus device to intercept all accesses through that OpRegion. This
+allows us to share the PCI BAR with the AML code if it for some reason is
+using it. We do not expect that this OpRegion handler will ever be called
+but if it is we print a warning and prevent all access from the SMBus
+driver itself.
+
+Link: https://bugzilla.kernel.org/show_bug.cgi?id=110041
+Reported-by: Andy Lutomirski <luto@kernel.org>
+Reported-by: Pali Rohár <pali.rohar@gmail.com>
+Suggested-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
+Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Reviewed-by: Jean Delvare <jdelvare@suse.de>
+Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
+Tested-by: Pali Rohár <pali.rohar@gmail.com>
+Tested-by: Jean Delvare <jdelvare@suse.de>
+Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/i2c/busses/i2c-i801.c | 103 ++++++++++++++++++++++++++++++++++++++----
+ 1 file changed, 94 insertions(+), 9 deletions(-)
+
+--- a/drivers/i2c/busses/i2c-i801.c
++++ b/drivers/i2c/busses/i2c-i801.c
+@@ -244,6 +244,13 @@ struct i801_priv {
+ struct platform_device *mux_pdev;
+ #endif
+ struct platform_device *tco_pdev;
++
++ /*
++ * If set to true the host controller registers are reserved for
++ * ACPI AML use. Protected by acpi_lock.
++ */
++ bool acpi_reserved;
++ struct mutex acpi_lock;
+ };
+
+ #define FEATURE_SMBUS_PEC (1 << 0)
+@@ -714,9 +721,15 @@ static s32 i801_access(struct i2c_adapte
+ {
+ int hwpec;
+ int block = 0;
+- int ret, xact = 0;
++ int ret = 0, xact = 0;
+ struct i801_priv *priv = i2c_get_adapdata(adap);
+
++ mutex_lock(&priv->acpi_lock);
++ if (priv->acpi_reserved) {
++ mutex_unlock(&priv->acpi_lock);
++ return -EBUSY;
++ }
++
+ hwpec = (priv->features & FEATURE_SMBUS_PEC) && (flags & I2C_CLIENT_PEC)
+ && size != I2C_SMBUS_QUICK
+ && size != I2C_SMBUS_I2C_BLOCK_DATA;
+@@ -773,7 +786,8 @@ static s32 i801_access(struct i2c_adapte
+ default:
+ dev_err(&priv->pci_dev->dev, "Unsupported transaction %d\n",
+ size);
+- return -EOPNOTSUPP;
++ ret = -EOPNOTSUPP;
++ goto out;
+ }
+
+ if (hwpec) /* enable/disable hardware PEC */
+@@ -796,11 +810,11 @@ static s32 i801_access(struct i2c_adapte
+ ~(SMBAUXCTL_CRC | SMBAUXCTL_E32B), SMBAUXCTL(priv));
+
+ if (block)
+- return ret;
++ goto out;
+ if (ret)
+- return ret;
++ goto out;
+ if ((read_write == I2C_SMBUS_WRITE) || (xact == I801_QUICK))
+- return 0;
++ goto out;
+
+ switch (xact & 0x7f) {
+ case I801_BYTE: /* Result put in SMBHSTDAT0 */
+@@ -812,7 +826,10 @@ static s32 i801_access(struct i2c_adapte
+ (inb_p(SMBHSTDAT1(priv)) << 8);
+ break;
+ }
+- return 0;
++
++out:
++ mutex_unlock(&priv->acpi_lock);
++ return ret;
+ }
+
+
+@@ -1249,6 +1266,72 @@ static void i801_add_tco(struct i801_pri
+ priv->tco_pdev = pdev;
+ }
+
++#ifdef CONFIG_ACPI
++static acpi_status
++i801_acpi_io_handler(u32 function, acpi_physical_address address, u32 bits,
++ u64 *value, void *handler_context, void *region_context)
++{
++ struct i801_priv *priv = handler_context;
++ struct pci_dev *pdev = priv->pci_dev;
++ acpi_status status;
++
++ /*
++ * Once BIOS AML code touches the OpRegion we warn and inhibit any
++ * further access from the driver itself. This device is now owned
++ * by the system firmware.
++ */
++ mutex_lock(&priv->acpi_lock);
++
++ if (!priv->acpi_reserved) {
++ priv->acpi_reserved = true;
++
++ dev_warn(&pdev->dev, "BIOS is accessing SMBus registers\n");
++ dev_warn(&pdev->dev, "Driver SMBus register access inhibited\n");
++ }
++
++ if ((function & ACPI_IO_MASK) == ACPI_READ)
++ status = acpi_os_read_port(address, (u32 *)value, bits);
++ else
++ status = acpi_os_write_port(address, (u32)*value, bits);
++
++ mutex_unlock(&priv->acpi_lock);
++
++ return status;
++}
++
++static int i801_acpi_probe(struct i801_priv *priv)
++{
++ struct acpi_device *adev;
++ acpi_status status;
++
++ adev = ACPI_COMPANION(&priv->pci_dev->dev);
++ if (adev) {
++ status = acpi_install_address_space_handler(adev->handle,
++ ACPI_ADR_SPACE_SYSTEM_IO, i801_acpi_io_handler,
++ NULL, priv);
++ if (ACPI_SUCCESS(status))
++ return 0;
++ }
++
++ return acpi_check_resource_conflict(&priv->pci_dev->resource[SMBBAR]);
++}
++
++static void i801_acpi_remove(struct i801_priv *priv)
++{
++ struct acpi_device *adev;
++
++ adev = ACPI_COMPANION(&priv->pci_dev->dev);
++ if (!adev)
++ return;
++
++ acpi_remove_address_space_handler(adev->handle,
++ ACPI_ADR_SPACE_SYSTEM_IO, i801_acpi_io_handler);
++}
++#else
++static inline int i801_acpi_probe(struct i801_priv *priv) { return 0; }
++static inline void i801_acpi_remove(struct i801_priv *priv) { }
++#endif
++
+ static int i801_probe(struct pci_dev *dev, const struct pci_device_id *id)
+ {
+ unsigned char temp;
+@@ -1266,6 +1349,7 @@ static int i801_probe(struct pci_dev *de
+ priv->adapter.dev.parent = &dev->dev;
+ ACPI_COMPANION_SET(&priv->adapter.dev, ACPI_COMPANION(&dev->dev));
+ priv->adapter.retries = 3;
++ mutex_init(&priv->acpi_lock);
+
+ priv->pci_dev = dev;
+ switch (dev->device) {
+@@ -1328,10 +1412,8 @@ static int i801_probe(struct pci_dev *de
+ return -ENODEV;
+ }
+
+- err = acpi_check_resource_conflict(&dev->resource[SMBBAR]);
+- if (err) {
++ if (i801_acpi_probe(priv))
+ return -ENODEV;
+- }
+
+ err = pcim_iomap_regions(dev, 1 << SMBBAR,
+ dev_driver_string(&dev->dev));
+@@ -1340,6 +1422,7 @@ static int i801_probe(struct pci_dev *de
+ "Failed to request SMBus region 0x%lx-0x%Lx\n",
+ priv->smba,
+ (unsigned long long)pci_resource_end(dev, SMBBAR));
++ i801_acpi_remove(priv);
+ return err;
+ }
+
+@@ -1404,6 +1487,7 @@ static int i801_probe(struct pci_dev *de
+ err = i2c_add_adapter(&priv->adapter);
+ if (err) {
+ dev_err(&dev->dev, "Failed to add SMBus adapter\n");
++ i801_acpi_remove(priv);
+ return err;
+ }
+
+@@ -1422,6 +1506,7 @@ static void i801_remove(struct pci_dev *
+
+ i801_del_mux(priv);
+ i2c_del_adapter(&priv->adapter);
++ i801_acpi_remove(priv);
+ pci_write_config_byte(dev, SMBHSTCFG, priv->original_hstcfg);
+
+ platform_device_unregister(priv->tco_pdev);
--- /dev/null
+From ben@decadent.org.uk Sun Aug 14 16:54:26 2016
+From: Ben Hutchings <ben@decadent.org.uk>
+Date: Tue, 31 May 2016 03:33:57 +0100
+Subject: ipath: Restrict use of the write() interface
+To: stable@vger.kernel.org
+Cc: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>, Doug Ledford <dledford@redhat.com>, linux-rdma@vger.kernel.org
+Message-ID: <20160531023356.GI7555@decadent.org.uk>
+Content-Disposition: inline
+
+From: Ben Hutchings <ben@decadent.org.uk>
+
+Commit e6bd18f57aad ("IB/security: Restrict use of the write()
+interface") fixed a security problem with various write()
+implementations in the Infiniband subsystem. In older kernel versions
+the ipath_write() function has the same problem and needs the same
+restriction. (The ipath driver has been completely removed upstream.)
+
+Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/staging/rdma/ipath/ipath_file_ops.c | 5 +++++
+ 1 file changed, 5 insertions(+)
+
+--- a/drivers/staging/rdma/ipath/ipath_file_ops.c
++++ b/drivers/staging/rdma/ipath/ipath_file_ops.c
+@@ -45,6 +45,8 @@
+ #include <linux/uio.h>
+ #include <asm/pgtable.h>
+
++#include <rdma/ib.h>
++
+ #include "ipath_kernel.h"
+ #include "ipath_common.h"
+ #include "ipath_user_sdma.h"
+@@ -2243,6 +2245,9 @@ static ssize_t ipath_write(struct file *
+ ssize_t ret = 0;
+ void *dest;
+
++ if (WARN_ON_ONCE(!ib_safe_file_access(fp)))
++ return -EACCES;
++
+ if (count < sizeof(cmd.type)) {
+ ret = -EINVAL;
+ goto bail;
--- /dev/null
+From 20f06ed9f61a185c6dabd662c310bed6189470df Mon Sep 17 00:00:00 2001
+From: David Howells <dhowells@redhat.com>
+Date: Wed, 27 Jul 2016 11:43:37 +0100
+Subject: KEYS: 64-bit MIPS needs to use compat_sys_keyctl for 32-bit userspace
+
+From: David Howells <dhowells@redhat.com>
+
+commit 20f06ed9f61a185c6dabd662c310bed6189470df upstream.
+
+MIPS64 needs to use compat_sys_keyctl for 32-bit userspace rather than
+calling sys_keyctl. The latter will work in a lot of cases, thereby hiding
+the issue.
+
+Reported-by: Stephan Mueller <smueller@chronox.de>
+Signed-off-by: David Howells <dhowells@redhat.com>
+Cc: linux-mips@linux-mips.org
+Cc: linux-kernel@vger.kernel.org
+Cc: linux-security-module@vger.kernel.org
+Cc: keyrings@vger.kernel.org
+Patchwork: https://patchwork.linux-mips.org/patch/13832/
+Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/mips/kernel/scall64-n32.S | 2 +-
+ arch/mips/kernel/scall64-o32.S | 2 +-
+ 2 files changed, 2 insertions(+), 2 deletions(-)
+
+--- a/arch/mips/kernel/scall64-n32.S
++++ b/arch/mips/kernel/scall64-n32.S
+@@ -344,7 +344,7 @@ EXPORT(sysn32_call_table)
+ PTR sys_ni_syscall /* available, was setaltroot */
+ PTR sys_add_key
+ PTR sys_request_key
+- PTR sys_keyctl /* 6245 */
++ PTR compat_sys_keyctl /* 6245 */
+ PTR sys_set_thread_area
+ PTR sys_inotify_init
+ PTR sys_inotify_add_watch
+--- a/arch/mips/kernel/scall64-o32.S
++++ b/arch/mips/kernel/scall64-o32.S
+@@ -500,7 +500,7 @@ EXPORT(sys32_call_table)
+ PTR sys_ni_syscall /* available, was setaltroot */
+ PTR sys_add_key /* 4280 */
+ PTR sys_request_key
+- PTR sys_keyctl
++ PTR compat_sys_keyctl
+ PTR sys_set_thread_area
+ PTR sys_inotify_init
+ PTR sys_inotify_add_watch /* 4285 */
--- /dev/null
+From a77060f07ffc6ac978e280e738302f3e5572a99e Mon Sep 17 00:00:00 2001
+From: Christophe Le Roy <christophe.fish@gmail.com>
+Date: Fri, 11 Dec 2015 09:13:42 +0100
+Subject: PNP: Add Broadwell to Intel MCH size workaround
+
+From: Christophe Le Roy <christophe.fish@gmail.com>
+
+commit a77060f07ffc6ac978e280e738302f3e5572a99e upstream.
+
+Add device ID 0x1604 for Broadwell to commit cb171f7abb9a ("PNP:
+Work around BIOS defects in Intel MCH area reporting").
+
+>From a Lenovo ThinkPad T550:
+
+ system 00:01: [io 0x1800-0x189f] could not be reserved
+ system 00:01: [io 0x0800-0x087f] has been reserved
+ system 00:01: [io 0x0880-0x08ff] has been reserved
+ system 00:01: [io 0x0900-0x097f] has been reserved
+ system 00:01: [io 0x0980-0x09ff] has been reserved
+ system 00:01: [io 0x0a00-0x0a7f] has been reserved
+ system 00:01: [io 0x0a80-0x0aff] has been reserved
+ system 00:01: [io 0x0b00-0x0b7f] has been reserved
+ system 00:01: [io 0x0b80-0x0bff] has been reserved
+ system 00:01: [io 0x15e0-0x15ef] has been reserved
+ system 00:01: [io 0x1600-0x167f] has been reserved
+ system 00:01: [io 0x1640-0x165f] has been reserved
+ system 00:01: [mem 0xf8000000-0xfbffffff] could not be reserved
+ system 00:01: [mem 0xfed1c000-0xfed1ffff] has been reserved
+ system 00:01: [mem 0xfed10000-0xfed13fff] has been reserved
+ system 00:01: [mem 0xfed18000-0xfed18fff] has been reserved
+ system 00:01: [mem 0xfed19000-0xfed19fff] has been reserved
+ system 00:01: [mem 0xfed45000-0xfed4bfff] has been reserved
+ system 00:01: Plug and Play ACPI device, IDs PNP0c02 (active)
+ [...]
+ resource sanity check: requesting [mem 0xfed10000-0xfed15fff], which spans more than pnp 00:01 [mem 0xfed10000-0xfed13fff]
+ ------------[ cut here ]------------
+ WARNING: CPU: 2 PID: 1 at /build/linux-CrHvZ_/linux-4.2.6/arch/x86/mm/ioremap.c:198 __ioremap_caller+0x2ee/0x360()
+ Info: mapping multiple BARs. Your kernel is fine.
+ Modules linked in:
+ CPU: 2 PID: 1 Comm: swapper/0 Not tainted 4.2.0-1-amd64 #1 Debian 4.2.6-1
+ Hardware name: LENOVO 20CKCTO1WW/20CKCTO1WW, BIOS N11ET34W (1.10 ) 08/20/2015
+ 0000000000000000 ffffffff817e6868 ffffffff8154e2f6 ffff8802241efbf8
+ ffffffff8106e5b1 ffffc90000e98000 0000000000006000 ffffc90000e98000
+ 0000000000006000 0000000000000000 ffffffff8106e62a ffffffff817e68c8
+ Call Trace:
+ [<ffffffff8154e2f6>] ? dump_stack+0x40/0x50
+ [<ffffffff8106e5b1>] ? warn_slowpath_common+0x81/0xb0
+ [<ffffffff8106e62a>] ? warn_slowpath_fmt+0x4a/0x50
+ [<ffffffff810742a3>] ? iomem_map_sanity_check+0xb3/0xc0
+ [<ffffffff8105dade>] ? __ioremap_caller+0x2ee/0x360
+ [<ffffffff81036ae6>] ? snb_uncore_imc_init_box+0x66/0x90
+ [<ffffffff810351a8>] ? uncore_pci_probe+0xc8/0x1a0
+ [<ffffffff81302d7f>] ? local_pci_probe+0x3f/0xa0
+ [<ffffffff81303ea4>] ? pci_device_probe+0xc4/0x110
+ [<ffffffff813d9b1e>] ? driver_probe_device+0x1ee/0x450
+ [<ffffffff813d9dfb>] ? __driver_attach+0x7b/0x80
+ [<ffffffff813d9d80>] ? driver_probe_device+0x450/0x450
+ [<ffffffff813d796a>] ? bus_for_each_dev+0x5a/0x90
+ [<ffffffff813d9091>] ? bus_add_driver+0x1f1/0x290
+ [<ffffffff81b37fa8>] ? uncore_cpu_setup+0xc/0xc
+ [<ffffffff813da73f>] ? driver_register+0x5f/0xe0
+ [<ffffffff81b38074>] ? intel_uncore_init+0xcc/0x2b0
+ [<ffffffff81b37fa8>] ? uncore_cpu_setup+0xc/0xc
+ [<ffffffff8100213e>] ? do_one_initcall+0xce/0x200
+ [<ffffffff8108a100>] ? parse_args+0x140/0x4e0
+ [<ffffffff81b2b0cb>] ? kernel_init_freeable+0x162/0x1e8
+ [<ffffffff815443f0>] ? rest_init+0x80/0x80
+ [<ffffffff815443fe>] ? kernel_init+0xe/0xf0
+ [<ffffffff81553e5f>] ? ret_from_fork+0x3f/0x70
+ [<ffffffff815443f0>] ? rest_init+0x80/0x80
+ ---[ end trace 472e7959536abf12 ]---
+
+ 00:00.0 Host bridge: Intel Corporation Broadwell-U Host Bridge -OPI (rev 09)
+ Subsystem: Lenovo Device 2223
+ Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
+ Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ >SERR- <PERR- INTx-
+ Latency: 0
+ Capabilities: [e0] Vendor Specific Information: Len=0c <?>
+ Kernel driver in use: bdw_uncore
+ 00: 86 80 04 16 06 00 90 20 09 00 00 06 00 00 00 00
+ 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+ 20: 00 00 00 00 00 00 00 00 00 00 00 00 aa 17 23 22
+ 30: 00 00 00 00 e0 00 00 00 00 00 00 00 00 00 00 00
+
+Signed-off-by: Christophe Le Roy <christophe.fish@gmail.com>
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Cc: Laura Abbott <labbott@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/pnp/quirks.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/pnp/quirks.c
++++ b/drivers/pnp/quirks.c
+@@ -344,6 +344,7 @@ static const unsigned int mch_quirk_devi
+ 0x0154, /* Ivy Bridge */
+ 0x0a04, /* Haswell-ULT */
+ 0x0c00, /* Haswell */
++ 0x1604, /* Broadwell */
+ };
+
+ static struct pci_dev *get_intel_host(void)
--- /dev/null
+From ed1f0eeebaeeb7f790e9e7642116a208581e5bfc Mon Sep 17 00:00:00 2001
+From: Josh Boyer <jwboyer@fedoraproject.org>
+Date: Wed, 3 Feb 2016 01:00:29 +0100
+Subject: PNP: Add Haswell-ULT to Intel MCH size workaround
+
+From: Josh Boyer <jwboyer@fedoraproject.org>
+
+commit ed1f0eeebaeeb7f790e9e7642116a208581e5bfc upstream.
+
+Add device ID 0x0a04 for Haswell-ULT to the list of devices with MCH
+problems.
+
+From a Lenovo ThinkPad T440S:
+[ 0.188604] pnp: PnP ACPI init
+[ 0.189044] system 00:00: [mem 0x00000000-0x0009ffff] could not be reserved
+[ 0.189048] system 00:00: [mem 0x000c0000-0x000c3fff] could not be reserved
+[ 0.189050] system 00:00: [mem 0x000c4000-0x000c7fff] could not be reserved
+[ 0.189052] system 00:00: [mem 0x000c8000-0x000cbfff] could not be reserved
+[ 0.189054] system 00:00: [mem 0x000cc000-0x000cffff] could not be reserved
+[ 0.189056] system 00:00: [mem 0x000d0000-0x000d3fff] has been reserved
+[ 0.189058] system 00:00: [mem 0x000d4000-0x000d7fff] has been reserved
+[ 0.189060] system 00:00: [mem 0x000d8000-0x000dbfff] has been reserved
+[ 0.189061] system 00:00: [mem 0x000dc000-0x000dffff] has been reserved
+[ 0.189063] system 00:00: [mem 0x000e0000-0x000e3fff] could not be reserved
+[ 0.189065] system 00:00: [mem 0x000e4000-0x000e7fff] could not be reserved
+[ 0.189067] system 00:00: [mem 0x000e8000-0x000ebfff] could not be reserved
+[ 0.189069] system 00:00: [mem 0x000ec000-0x000effff] could not be reserved
+[ 0.189071] system 00:00: [mem 0x000f0000-0x000fffff] could not be reserved
+[ 0.189073] system 00:00: [mem 0x00100000-0xdf9fffff] could not be reserved
+[ 0.189075] system 00:00: [mem 0xfec00000-0xfed3ffff] could not be reserved
+[ 0.189078] system 00:00: [mem 0xfed4c000-0xffffffff] could not be reserved
+[ 0.189082] system 00:00: Plug and Play ACPI device, IDs PNP0c01 (active)
+[ 0.189216] system 00:01: [io 0x1800-0x189f] could not be reserved
+[ 0.189220] system 00:01: [io 0x0800-0x087f] has been reserved
+[ 0.189222] system 00:01: [io 0x0880-0x08ff] has been reserved
+[ 0.189224] system 00:01: [io 0x0900-0x097f] has been reserved
+[ 0.189226] system 00:01: [io 0x0980-0x09ff] has been reserved
+[ 0.189229] system 00:01: [io 0x0a00-0x0a7f] has been reserved
+[ 0.189231] system 00:01: [io 0x0a80-0x0aff] has been reserved
+[ 0.189233] system 00:01: [io 0x0b00-0x0b7f] has been reserved
+[ 0.189235] system 00:01: [io 0x0b80-0x0bff] has been reserved
+[ 0.189238] system 00:01: [io 0x15e0-0x15ef] has been reserved
+[ 0.189240] system 00:01: [io 0x1600-0x167f] has been reserved
+[ 0.189242] system 00:01: [io 0x1640-0x165f] has been reserved
+[ 0.189246] system 00:01: [mem 0xf8000000-0xfbffffff] could not be reserved
+[ 0.189249] system 00:01: [mem 0x00000000-0x00000fff] could not be reserved
+[ 0.189251] system 00:01: [mem 0xfed1c000-0xfed1ffff] has been reserved
+[ 0.189254] system 00:01: [mem 0xfed10000-0xfed13fff] has been reserved
+[ 0.189256] system 00:01: [mem 0xfed18000-0xfed18fff] has been reserved
+[ 0.189258] system 00:01: [mem 0xfed19000-0xfed19fff] has been reserved
+[ 0.189261] system 00:01: [mem 0xfed45000-0xfed4bfff] has been reserved
+[ 0.189264] system 00:01: Plug and Play ACPI device, IDs PNP0c02 (active)
+[....]
+[ 0.583653] resource sanity check: requesting [mem 0xfed10000-0xfed15fff], which spans more than pnp 00:01 [mem 0xfed10000-0xfed13fff]
+[ 0.583654] ------------[ cut here ]------------
+[ 0.583660] WARNING: CPU: 0 PID: 1 at arch/x86/mm/ioremap.c:198 __ioremap_caller+0x2c5/0x380()
+[ 0.583661] Info: mapping multiple BARs. Your kernel is fine.
+[ 0.583662] Modules linked in:
+
+[ 0.583666] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.3.3-303.fc23.x86_64 #1
+[ 0.583668] Hardware name: LENOVO 20AR001GXS/20AR001GXS, BIOS GJET86WW (2.36 ) 12/04/2015
+[ 0.583670] 0000000000000000 0000000014cf7e59 ffff880214a1baf8 ffffffff813a625f
+[ 0.583673] ffff880214a1bb40 ffff880214a1bb30 ffffffff810a07c2 00000000fed10000
+[ 0.583675] ffffc90000cb8000 0000000000006000 0000000000000000 ffff8800d6381040
+[ 0.583678] Call Trace:
+[ 0.583683] [<ffffffff813a625f>] dump_stack+0x44/0x55
+[ 0.583686] [<ffffffff810a07c2>] warn_slowpath_common+0x82/0xc0
+[ 0.583688] [<ffffffff810a085c>] warn_slowpath_fmt+0x5c/0x80
+[ 0.583692] [<ffffffff810a6fba>] ? iomem_map_sanity_check+0xba/0xd0
+[ 0.583695] [<ffffffff81065835>] __ioremap_caller+0x2c5/0x380
+[ 0.583698] [<ffffffff81065907>] ioremap_nocache+0x17/0x20
+[ 0.583701] [<ffffffff8103a119>] snb_uncore_imc_init_box+0x79/0xb0
+[ 0.583705] [<ffffffff81038900>] uncore_pci_probe+0xd0/0x1b0
+[ 0.583707] [<ffffffff813efda5>] local_pci_probe+0x45/0xa0
+[ 0.583710] [<ffffffff813f118d>] pci_device_probe+0xfd/0x140
+[ 0.583713] [<ffffffff814d9b52>] driver_probe_device+0x222/0x480
+[ 0.583715] [<ffffffff814d9e34>] __driver_attach+0x84/0x90
+[ 0.583717] [<ffffffff814d9db0>] ? driver_probe_device+0x480/0x480
+[ 0.583720] [<ffffffff814d762c>] bus_for_each_dev+0x6c/0xc0
+[ 0.583722] [<ffffffff814d930e>] driver_attach+0x1e/0x20
+[ 0.583724] [<ffffffff814d8e4b>] bus_add_driver+0x1eb/0x280
+[ 0.583727] [<ffffffff81d6af1a>] ? uncore_cpu_setup+0x12/0x12
+[ 0.583729] [<ffffffff814da680>] driver_register+0x60/0xe0
+[ 0.583733] [<ffffffff813ef78c>] __pci_register_driver+0x4c/0x50
+[ 0.583736] [<ffffffff81d6affc>] intel_uncore_init+0xe2/0x2e6
+[ 0.583738] [<ffffffff81d6af1a>] ? uncore_cpu_setup+0x12/0x12
+[ 0.583741] [<ffffffff81002123>] do_one_initcall+0xb3/0x200
+[ 0.583745] [<ffffffff810be500>] ? parse_args+0x1a0/0x4a0
+[ 0.583749] [<ffffffff81d5c1c8>] kernel_init_freeable+0x189/0x223
+[ 0.583752] [<ffffffff81775c40>] ? rest_init+0x80/0x80
+[ 0.583754] [<ffffffff81775c4e>] kernel_init+0xe/0xe0
+[ 0.583758] [<ffffffff81781adf>] ret_from_fork+0x3f/0x70
+[ 0.583760] [<ffffffff81775c40>] ? rest_init+0x80/0x80
+[ 0.583765] ---[ end trace 077c426a39e018aa ]---
+
+00:00.0 Host bridge [0600]: Intel Corporation Haswell-ULT DRAM Controller [8086:0a04] (rev 0b)
+ Subsystem: Lenovo Device [17aa:220c]
+ Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
+ Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ >SERR- <PERR- INTx-
+ Latency: 0
+ Capabilities: <access denied>
+ Kernel driver in use: hsw_uncore
+
+Link: https://bugzilla.redhat.com/show_bug.cgi?id=1300955
+Tested-by: <robo@tcp.sk>
+Signed-off-by: Josh Boyer <jwboyer@fedoraproject.org>
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Cc: Laura Abbott <labbott@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/pnp/quirks.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/pnp/quirks.c
++++ b/drivers/pnp/quirks.c
+@@ -342,6 +342,7 @@ static void quirk_amd_mmconfig_area(stru
+ /* Device IDs of parts that have 32KB MCH space */
+ static const unsigned int mch_quirk_devices[] = {
+ 0x0154, /* Ivy Bridge */
++ 0x0a04, /* Haswell-ULT */
+ 0x0c00, /* Haswell */
+ };
+
--- /dev/null
+From 86a574de4590ffe6fd3f3ca34cdcf655a78e36ec Mon Sep 17 00:00:00 2001
+From: Theodore Ts'o <tytso@mit.edu>
+Date: Sun, 3 Jul 2016 17:01:26 -0400
+Subject: random: strengthen input validation for RNDADDTOENTCNT
+
+From: Theodore Ts'o <tytso@mit.edu>
+
+commit 86a574de4590ffe6fd3f3ca34cdcf655a78e36ec upstream.
+
+Don't allow RNDADDTOENTCNT or RNDADDENTROPY to accept a negative
+entropy value. It doesn't make any sense to subtract from the entropy
+counter, and it can trigger a warning:
+
+random: negative entropy/overflow: pool input count -40000
+------------[ cut here ]------------
+WARNING: CPU: 3 PID: 6828 at drivers/char/random.c:670[< none
+ >] credit_entropy_bits+0x21e/0xad0 drivers/char/random.c:670
+Modules linked in:
+CPU: 3 PID: 6828 Comm: a.out Not tainted 4.7.0-rc4+ #4
+Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
+ ffffffff880b58e0 ffff88005dd9fcb0 ffffffff82cc838f ffffffff87158b40
+ fffffbfff1016b1c 0000000000000000 0000000000000000 ffffffff87158b40
+ ffffffff83283dae 0000000000000009 ffff88005dd9fcf8 ffffffff8136d27f
+Call Trace:
+ [< inline >] __dump_stack lib/dump_stack.c:15
+ [<ffffffff82cc838f>] dump_stack+0x12e/0x18f lib/dump_stack.c:51
+ [<ffffffff8136d27f>] __warn+0x19f/0x1e0 kernel/panic.c:516
+ [<ffffffff8136d48c>] warn_slowpath_null+0x2c/0x40 kernel/panic.c:551
+ [<ffffffff83283dae>] credit_entropy_bits+0x21e/0xad0 drivers/char/random.c:670
+ [< inline >] credit_entropy_bits_safe drivers/char/random.c:734
+ [<ffffffff8328785d>] random_ioctl+0x21d/0x250 drivers/char/random.c:1546
+ [< inline >] vfs_ioctl fs/ioctl.c:43
+ [<ffffffff8185316c>] do_vfs_ioctl+0x18c/0xff0 fs/ioctl.c:674
+ [< inline >] SYSC_ioctl fs/ioctl.c:689
+ [<ffffffff8185405f>] SyS_ioctl+0x8f/0xc0 fs/ioctl.c:680
+ [<ffffffff86a995c0>] entry_SYSCALL_64_fastpath+0x23/0xc1
+arch/x86/entry/entry_64.S:207
+---[ end trace 5d4902b2ba842f1f ]---
+
+This was triggered using the test program:
+
+// autogenerated by syzkaller (http://github.com/google/syzkaller)
+
+int main() {
+ int fd = open("/dev/random", O_RDWR);
+ int val = -5000;
+ ioctl(fd, RNDADDTOENTCNT, &val);
+ return 0;
+}
+
+It's harmless in that (a) only root can trigger it, and (b) after
+complaining the code never does let the entropy count go negative, but
+it's better to simply not allow this userspace from passing in a
+negative entropy value altogether.
+
+Google-Bug-Id: #29575089
+Reported-By: Dmitry Vyukov <dvyukov@google.com>
+Signed-off-by: Theodore Ts'o <tytso@mit.edu>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/char/random.c | 13 +++++++------
+ 1 file changed, 7 insertions(+), 6 deletions(-)
+
+--- a/drivers/char/random.c
++++ b/drivers/char/random.c
+@@ -722,15 +722,18 @@ retry:
+ }
+ }
+
+-static void credit_entropy_bits_safe(struct entropy_store *r, int nbits)
++static int credit_entropy_bits_safe(struct entropy_store *r, int nbits)
+ {
+ const int nbits_max = (int)(~0U >> (ENTROPY_SHIFT + 1));
+
++ if (nbits < 0)
++ return -EINVAL;
++
+ /* Cap the value to avoid overflows */
+ nbits = min(nbits, nbits_max);
+- nbits = max(nbits, -nbits_max);
+
+ credit_entropy_bits(r, nbits);
++ return 0;
+ }
+
+ /*********************************************************************
+@@ -1542,8 +1545,7 @@ static long random_ioctl(struct file *f,
+ return -EPERM;
+ if (get_user(ent_count, p))
+ return -EFAULT;
+- credit_entropy_bits_safe(&input_pool, ent_count);
+- return 0;
++ return credit_entropy_bits_safe(&input_pool, ent_count);
+ case RNDADDENTROPY:
+ if (!capable(CAP_SYS_ADMIN))
+ return -EPERM;
+@@ -1557,8 +1559,7 @@ static long random_ioctl(struct file *f,
+ size);
+ if (retval < 0)
+ return retval;
+- credit_entropy_bits_safe(&input_pool, ent_count);
+- return 0;
++ return credit_entropy_bits_safe(&input_pool, ent_count);
+ case RNDZAPENTCNT:
+ case RNDCLEARPOOL:
+ /*
--- /dev/null
+From 5419447e2142d6ed68c9f5c1a28630b3a290a845 Mon Sep 17 00:00:00 2001
+From: Michael Holzheu <holzheu@linux.vnet.ibm.com>
+Date: Mon, 13 Jun 2016 17:03:48 +0200
+Subject: Revert "s390/kdump: Clear subchannel ID to signal non-CCW/SCSI IPL"
+
+From: Michael Holzheu <holzheu@linux.vnet.ibm.com>
+
+commit 5419447e2142d6ed68c9f5c1a28630b3a290a845 upstream.
+
+This reverts commit 852ffd0f4e23248b47531058e531066a988434b5.
+
+There are use cases where an intermediate boot kernel (1) uses kexec
+to boot the final production kernel (2). For this scenario we should
+provide the original boot information to the production kernel (2).
+Therefore clearing the boot information during kexec() should not
+be done.
+
+Reported-by: Steffen Maier <maier@linux.vnet.ibm.com>
+Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
+Reviewed-by: Heiko Carstens <heiko.carstens@de.ibm.com>
+Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/s390/kernel/ipl.c | 7 -------
+ 1 file changed, 7 deletions(-)
+
+--- a/arch/s390/kernel/ipl.c
++++ b/arch/s390/kernel/ipl.c
+@@ -2070,13 +2070,6 @@ void s390_reset_system(void (*fn_pre)(vo
+ S390_lowcore.program_new_psw.addr =
+ PSW_ADDR_AMODE | (unsigned long) s390_base_pgm_handler;
+
+- /*
+- * Clear subchannel ID and number to signal new kernel that no CCW or
+- * SCSI IPL has been done (for kexec and kdump)
+- */
+- S390_lowcore.subchannel_id = 0;
+- S390_lowcore.subchannel_nr = 0;
+-
+ /* Store status at absolute zero */
+ store_status();
+
--- /dev/null
+From 221255aee67ec1c752001080aafec0c4e9390d95 Mon Sep 17 00:00:00 2001
+From: Hannes Reinecke <hare@suse.de>
+Date: Tue, 1 Dec 2015 10:16:42 +0100
+Subject: scsi: ignore errors from scsi_dh_add_device()
+
+From: Hannes Reinecke <hare@suse.de>
+
+commit 221255aee67ec1c752001080aafec0c4e9390d95 upstream.
+
+device handler initialisation might fail due to a number of
+reasons. But as device_handlers are optional this shouldn't
+cause us to disable the device entirely.
+So just ignore errors from scsi_dh_add_device().
+
+Reviewed-by: Johannes Thumshirn <jthumshirn@suse.com>
+Reviewed-by: Christoph Hellwig <hch@lst.de>
+Signed-off-by: Hannes Reinecke <hare@suse.de>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Cc: Laura Abbott <labbott@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/scsi/scsi_sysfs.c | 7 ++++---
+ 1 file changed, 4 insertions(+), 3 deletions(-)
+
+--- a/drivers/scsi/scsi_sysfs.c
++++ b/drivers/scsi/scsi_sysfs.c
+@@ -1058,11 +1058,12 @@ int scsi_sysfs_add_sdev(struct scsi_devi
+ }
+
+ error = scsi_dh_add_device(sdev);
+- if (error) {
++ if (error)
++ /*
++ * device_handler is optional, so any error can be ignored
++ */
+ sdev_printk(KERN_INFO, sdev,
+ "failed to add device handler: %d\n", error);
+- return error;
+- }
+
+ device_enable_async_suspend(&sdev->sdev_dev);
+ error = device_add(&sdev->sdev_dev);
net-irda-fix-null-pointer-dereference-on-memory-allocation-failure.patch
qed-fix-setting-clearing-bit-in-completion-bitmap.patch
tcp-consider-recv-buf-for-the-initial-window-scale.patch
+ipath-restrict-use-of-the-write-interface.patch
+scsi-ignore-errors-from-scsi_dh_add_device.patch
+pnp-add-haswell-ult-to-intel-mch-size-workaround.patch
+pnp-add-broadwell-to-intel-mch-size-workaround.patch
+hid-sony-do-not-bail-out-when-the-sixaxis-refuses-the-output-report.patch
+x86-mm-32-enable-full-randomization-on-i386-and-x86_32.patch
+i2c-i801-allow-acpi-systemio-opregion-to-conflict-with-pci-bar.patch
+cdc_ncm-do-not-call-usbnet_link_change-from-cdc_ncm_bind.patch
+arm-oabi-compat-add-missing-access-checks.patch
+keys-64-bit-mips-needs-to-use-compat_sys_keyctl-for-32-bit-userspace.patch
+revert-s390-kdump-clear-subchannel-id-to-signal-non-ccw-scsi-ipl.patch
+apparmor-fix-ref-count-leak-when-profile-sha1-hash-is-read.patch
+random-strengthen-input-validation-for-rndaddtoentcnt.patch
+devpts-clean-up-interface-to-pty-drivers.patch
+x86-mm-pat-add-support-of-non-default-pat-msr-setting.patch
+x86-mm-pat-add-pat_disable-interface.patch
+x86-mm-pat-replace-cpu_has_pat-with-boot_cpu_has.patch
+x86-mtrr-fix-xorg-crashes-in-qemu-sessions.patch
+x86-mtrr-fix-pat-init-handling-when-mtrr-is-disabled.patch
+x86-xen-pat-remove-pat-table-init-code-from-xen.patch
+x86-pat-document-the-pat-initialization-sequence.patch
+x86-mm-pat-fix-bug_on-in-mmap_mem-on-qemu-i386.patch
+drm-i915-pretend-cursor-is-always-on-for-ilk-style-wm-calculations-v2.patch
--- /dev/null
+From 8b8addf891de8a00e4d39fc32f93f7c5eb8feceb Mon Sep 17 00:00:00 2001
+From: Hector Marco-Gisbert <hecmargi@upv.es>
+Date: Thu, 10 Mar 2016 20:51:00 +0100
+Subject: x86/mm/32: Enable full randomization on i386 and X86_32
+
+From: Hector Marco-Gisbert <hecmargi@upv.es>
+
+commit 8b8addf891de8a00e4d39fc32f93f7c5eb8feceb upstream.
+
+Currently on i386 and on X86_64 when emulating X86_32 in legacy mode, only
+the stack and the executable are randomized but not other mmapped files
+(libraries, vDSO, etc.). This patch enables randomization for the
+libraries, vDSO and mmap requests on i386 and in X86_32 in legacy mode.
+
+By default on i386 there are 8 bits for the randomization of the libraries,
+vDSO and mmaps which only uses 1MB of VA.
+
+This patch preserves the original randomness, using 1MB of VA out of 3GB or
+4GB. We think that 1MB out of 3GB is not a big cost for having the ASLR.
+
+The first obvious security benefit is that all objects are randomized (not
+only the stack and the executable) in legacy mode which highly increases
+the ASLR effectiveness, otherwise the attackers may use these
+non-randomized areas. But also sensitive setuid/setgid applications are
+more secure because currently, attackers can disable the randomization of
+these applications by setting the ulimit stack to "unlimited". This is a
+very old and widely known trick to disable the ASLR in i386 which has been
+allowed for too long.
+
+Another trick used to disable the ASLR was to set the ADDR_NO_RANDOMIZE
+personality flag, but fortunately this doesn't work on setuid/setgid
+applications because there is security checks which clear Security-relevant
+flags.
+
+This patch always randomizes the mmap_legacy_base address, removing the
+possibility to disable the ASLR by setting the stack to "unlimited".
+
+Signed-off-by: Hector Marco-Gisbert <hecmargi@upv.es>
+Acked-by: Ismael Ripoll Ripoll <iripoll@upv.es>
+Acked-by: Kees Cook <keescook@chromium.org>
+Acked-by: Arjan van de Ven <arjan@linux.intel.com>
+Cc: Linus Torvalds <torvalds@linux-foundation.org>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Cc: Thomas Gleixner <tglx@linutronix.de>
+Cc: akpm@linux-foundation.org
+Cc: kees Cook <keescook@chromium.org>
+Link: http://lkml.kernel.org/r/1457639460-5242-1-git-send-email-hecmargi@upv.es
+Signed-off-by: Ingo Molnar <mingo@kernel.org>
+Cc: Laura Abbott <labbott@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/mm/mmap.c | 14 +-------------
+ 1 file changed, 1 insertion(+), 13 deletions(-)
+
+--- a/arch/x86/mm/mmap.c
++++ b/arch/x86/mm/mmap.c
+@@ -94,18 +94,6 @@ static unsigned long mmap_base(unsigned
+ }
+
+ /*
+- * Bottom-up (legacy) layout on X86_32 did not support randomization, X86_64
+- * does, but not when emulating X86_32
+- */
+-static unsigned long mmap_legacy_base(unsigned long rnd)
+-{
+- if (mmap_is_ia32())
+- return TASK_UNMAPPED_BASE;
+- else
+- return TASK_UNMAPPED_BASE + rnd;
+-}
+-
+-/*
+ * This function, called very early during the creation of a new
+ * process VM image, sets up which VM layout function to use:
+ */
+@@ -116,7 +104,7 @@ void arch_pick_mmap_layout(struct mm_str
+ if (current->flags & PF_RANDOMIZE)
+ random_factor = arch_mmap_rnd();
+
+- mm->mmap_legacy_base = mmap_legacy_base(random_factor);
++ mm->mmap_legacy_base = TASK_UNMAPPED_BASE + random_factor;
+
+ if (mmap_is_legacy()) {
+ mm->mmap_base = mm->mmap_legacy_base;
--- /dev/null
+From 224bb1e5d67ba0f2872c98002d6a6f991ac6fd4a Mon Sep 17 00:00:00 2001
+From: Toshi Kani <toshi.kani@hpe.com>
+Date: Wed, 23 Mar 2016 15:41:58 -0600
+Subject: x86/mm/pat: Add pat_disable() interface
+
+From: Toshi Kani <toshi.kani@hpe.com>
+
+commit 224bb1e5d67ba0f2872c98002d6a6f991ac6fd4a upstream.
+
+In preparation for fixing a regression caused by:
+
+ 9cd25aac1f44 ("x86/mm/pat: Emulate PAT when it is disabled")
+
+... PAT needs to provide an interface that prevents the OS from
+initializing the PAT MSR.
+
+PAT MSR initialization must be done on all CPUs using the specific
+sequence of operations defined in the Intel SDM. This requires MTRRs
+to be enabled since pat_init() is called as part of MTRR init
+from mtrr_rendezvous_handler().
+
+Make pat_disable() as the interface that prevents the OS from
+initializing the PAT MSR. MTRR will call this interface when it
+cannot provide the SDM-defined sequence to initialize PAT.
+
+This also assures that pat_disable() called from pat_bsp_init()
+will set the PAT table properly when CPU does not support PAT.
+
+Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
+Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
+Cc: Andrew Morton <akpm@linux-foundation.org>
+Cc: Andy Lutomirski <luto@amacapital.net>
+Cc: Borislav Petkov <bp@alien8.de>
+Cc: Borislav Petkov <bp@suse.de>
+Cc: Brian Gerst <brgerst@gmail.com>
+Cc: Denys Vlasenko <dvlasenk@redhat.com>
+Cc: H. Peter Anvin <hpa@zytor.com>
+Cc: Juergen Gross <jgross@suse.com>
+Cc: Linus Torvalds <torvalds@linux-foundation.org>
+Cc: Luis R. Rodriguez <mcgrof@suse.com>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Cc: Robert Elliott <elliott@hpe.com>
+Cc: Toshi Kani <toshi.kani@hp.com>
+Cc: konrad.wilk@oracle.com
+Cc: paul.gortmaker@windriver.com
+Cc: xen-devel@lists.xenproject.org
+Link: http://lkml.kernel.org/r/1458769323-24491-3-git-send-email-toshi.kani@hpe.com
+Signed-off-by: Ingo Molnar <mingo@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/include/asm/pat.h | 1 +
+ arch/x86/mm/pat.c | 13 ++++++++++++-
+ 2 files changed, 13 insertions(+), 1 deletion(-)
+
+--- a/arch/x86/include/asm/pat.h
++++ b/arch/x86/include/asm/pat.h
+@@ -5,6 +5,7 @@
+ #include <asm/pgtable_types.h>
+
+ bool pat_enabled(void);
++void pat_disable(const char *reason);
+ extern void pat_init(void);
+ void __init_cache_modes(u64);
+
+--- a/arch/x86/mm/pat.c
++++ b/arch/x86/mm/pat.c
+@@ -39,11 +39,22 @@
+ static bool boot_cpu_done;
+
+ static int __read_mostly __pat_enabled = IS_ENABLED(CONFIG_X86_PAT);
++static void init_cache_modes(void);
+
+-static inline void pat_disable(const char *reason)
++void pat_disable(const char *reason)
+ {
++ if (!__pat_enabled)
++ return;
++
++ if (boot_cpu_done) {
++ WARN_ONCE(1, "x86/PAT: PAT cannot be disabled after initialization\n");
++ return;
++ }
++
+ __pat_enabled = 0;
+ pr_info("x86/PAT: %s\n", reason);
++
++ init_cache_modes();
+ }
+
+ static int __init nopat(char *str)
--- /dev/null
+From 02f037d641dc6672be5cfe7875a48ab99b95b154 Mon Sep 17 00:00:00 2001
+From: Toshi Kani <toshi.kani@hpe.com>
+Date: Wed, 23 Mar 2016 15:41:57 -0600
+Subject: x86/mm/pat: Add support of non-default PAT MSR setting
+
+From: Toshi Kani <toshi.kani@hpe.com>
+
+commit 02f037d641dc6672be5cfe7875a48ab99b95b154 upstream.
+
+In preparation for fixing a regression caused by:
+
+ 9cd25aac1f44 ("x86/mm/pat: Emulate PAT when it is disabled")'
+
+... PAT needs to support a case that PAT MSR is initialized with a
+non-default value.
+
+When pat_init() is called and PAT is disabled, it initializes the
+PAT table with the BIOS default value. Xen, however, sets PAT MSR
+with a non-default value to enable WC. This causes inconsistency
+between the PAT table and PAT MSR when PAT is set to disable on Xen.
+
+Change pat_init() to handle the PAT disable cases properly. Add
+init_cache_modes() to handle two cases when PAT is set to disable.
+
+ 1. CPU supports PAT: Set PAT table to be consistent with PAT MSR.
+ 2. CPU does not support PAT: Set PAT table to be consistent with
+ PWT and PCD bits in a PTE.
+
+Note, __init_cache_modes(), renamed from pat_init_cache_modes(),
+will be changed to a static function in a later patch.
+
+Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
+Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
+Cc: Andrew Morton <akpm@linux-foundation.org>
+Cc: Andy Lutomirski <luto@amacapital.net>
+Cc: Borislav Petkov <bp@alien8.de>
+Cc: Borislav Petkov <bp@suse.de>
+Cc: Brian Gerst <brgerst@gmail.com>
+Cc: Denys Vlasenko <dvlasenk@redhat.com>
+Cc: H. Peter Anvin <hpa@zytor.com>
+Cc: Juergen Gross <jgross@suse.com>
+Cc: Linus Torvalds <torvalds@linux-foundation.org>
+Cc: Luis R. Rodriguez <mcgrof@suse.com>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Cc: Toshi Kani <toshi.kani@hp.com>
+Cc: elliott@hpe.com
+Cc: konrad.wilk@oracle.com
+Cc: paul.gortmaker@windriver.com
+Cc: xen-devel@lists.xenproject.org
+Link: http://lkml.kernel.org/r/1458769323-24491-2-git-send-email-toshi.kani@hpe.com
+Signed-off-by: Ingo Molnar <mingo@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/include/asm/pat.h | 2 -
+ arch/x86/mm/pat.c | 73 ++++++++++++++++++++++++++++++++-------------
+ arch/x86/xen/enlighten.c | 2 -
+ 3 files changed, 55 insertions(+), 22 deletions(-)
+
+--- a/arch/x86/include/asm/pat.h
++++ b/arch/x86/include/asm/pat.h
+@@ -6,7 +6,7 @@
+
+ bool pat_enabled(void);
+ extern void pat_init(void);
+-void pat_init_cache_modes(u64);
++void __init_cache_modes(u64);
+
+ extern int reserve_memtype(u64 start, u64 end,
+ enum page_cache_mode req_pcm, enum page_cache_mode *ret_pcm);
+--- a/arch/x86/mm/pat.c
++++ b/arch/x86/mm/pat.c
+@@ -180,7 +180,7 @@ static enum page_cache_mode pat_get_cach
+ * configuration.
+ * Using lower indices is preferred, so we start with highest index.
+ */
+-void pat_init_cache_modes(u64 pat)
++void __init_cache_modes(u64 pat)
+ {
+ enum page_cache_mode cache;
+ char pat_msg[33];
+@@ -206,9 +206,6 @@ static void pat_bsp_init(u64 pat)
+ return;
+ }
+
+- if (!pat_enabled())
+- goto done;
+-
+ rdmsrl(MSR_IA32_CR_PAT, tmp_pat);
+ if (!tmp_pat) {
+ pat_disable("PAT MSR is 0, disabled.");
+@@ -217,15 +214,11 @@ static void pat_bsp_init(u64 pat)
+
+ wrmsrl(MSR_IA32_CR_PAT, pat);
+
+-done:
+- pat_init_cache_modes(pat);
++ __init_cache_modes(pat);
+ }
+
+ static void pat_ap_init(u64 pat)
+ {
+- if (!pat_enabled())
+- return;
+-
+ if (!cpu_has_pat) {
+ /*
+ * If this happens we are on a secondary CPU, but switched to
+@@ -237,18 +230,32 @@ static void pat_ap_init(u64 pat)
+ wrmsrl(MSR_IA32_CR_PAT, pat);
+ }
+
+-void pat_init(void)
++static void init_cache_modes(void)
+ {
+- u64 pat;
+- struct cpuinfo_x86 *c = &boot_cpu_data;
++ u64 pat = 0;
++ static int init_cm_done;
+
+- if (!pat_enabled()) {
++ if (init_cm_done)
++ return;
++
++ if (boot_cpu_has(X86_FEATURE_PAT)) {
++ /*
++ * CPU supports PAT. Set PAT table to be consistent with
++ * PAT MSR. This case supports "nopat" boot option, and
++ * virtual machine environments which support PAT without
++ * MTRRs. In specific, Xen has unique setup to PAT MSR.
++ *
++ * If PAT MSR returns 0, it is considered invalid and emulates
++ * as No PAT.
++ */
++ rdmsrl(MSR_IA32_CR_PAT, pat);
++ }
++
++ if (!pat) {
+ /*
+ * No PAT. Emulate the PAT table that corresponds to the two
+- * cache bits, PWT (Write Through) and PCD (Cache Disable). This
+- * setup is the same as the BIOS default setup when the system
+- * has PAT but the "nopat" boot option has been specified. This
+- * emulated PAT table is used when MSR_IA32_CR_PAT returns 0.
++ * cache bits, PWT (Write Through) and PCD (Cache Disable).
++ * This setup is also the same as the BIOS default setup.
+ *
+ * PTE encoding:
+ *
+@@ -265,10 +272,36 @@ void pat_init(void)
+ */
+ pat = PAT(0, WB) | PAT(1, WT) | PAT(2, UC_MINUS) | PAT(3, UC) |
+ PAT(4, WB) | PAT(5, WT) | PAT(6, UC_MINUS) | PAT(7, UC);
++ }
++
++ __init_cache_modes(pat);
++
++ init_cm_done = 1;
++}
++
++/**
++ * pat_init - Initialize PAT MSR and PAT table
++ *
++ * This function initializes PAT MSR and PAT table with an OS-defined value
++ * to enable additional cache attributes, WC and WT.
++ *
++ * This function must be called on all CPUs using the specific sequence of
++ * operations defined in Intel SDM. mtrr_rendezvous_handler() provides this
++ * procedure for PAT.
++ */
++void pat_init(void)
++{
++ u64 pat;
++ struct cpuinfo_x86 *c = &boot_cpu_data;
++
++ if (!pat_enabled()) {
++ init_cache_modes();
++ return;
++ }
+
+- } else if ((c->x86_vendor == X86_VENDOR_INTEL) &&
+- (((c->x86 == 0x6) && (c->x86_model <= 0xd)) ||
+- ((c->x86 == 0xf) && (c->x86_model <= 0x6)))) {
++ if ((c->x86_vendor == X86_VENDOR_INTEL) &&
++ (((c->x86 == 0x6) && (c->x86_model <= 0xd)) ||
++ ((c->x86 == 0xf) && (c->x86_model <= 0x6)))) {
+ /*
+ * PAT support with the lower four entries. Intel Pentium 2,
+ * 3, M, and 4 are affected by PAT errata, which makes the
+--- a/arch/x86/xen/enlighten.c
++++ b/arch/x86/xen/enlighten.c
+@@ -1632,7 +1632,7 @@ asmlinkage __visible void __init xen_sta
+ * configuration.
+ */
+ rdmsrl(MSR_IA32_CR_PAT, pat);
+- pat_init_cache_modes(pat);
++ __init_cache_modes(pat);
+
+ /* keep using Xen gdt for now; no urgent need to change it */
+
--- /dev/null
+From 1886297ce0c8d563a08c8a8c4c0b97743e06cd37 Mon Sep 17 00:00:00 2001
+From: Toshi Kani <toshi.kani@hpe.com>
+Date: Mon, 11 Apr 2016 13:36:00 -0600
+Subject: x86/mm/pat: Fix BUG_ON() in mmap_mem() on QEMU/i386
+
+From: Toshi Kani <toshi.kani@hpe.com>
+
+commit 1886297ce0c8d563a08c8a8c4c0b97743e06cd37 upstream.
+
+The following BUG_ON() crash was reported on QEMU/i386:
+
+ kernel BUG at arch/x86/mm/physaddr.c:79!
+ Call Trace:
+ phys_mem_access_prot_allowed
+ mmap_mem
+ ? mmap_region
+ mmap_region
+ do_mmap
+ vm_mmap_pgoff
+ SyS_mmap_pgoff
+ do_int80_syscall_32
+ entry_INT80_32
+
+after commit:
+
+ edfe63ec97ed ("x86/mtrr: Fix Xorg crashes in Qemu sessions")
+
+PAT is now set to disabled state when MTRRs are disabled.
+Thus, reactivating the __pa(high_memory) check in
+phys_mem_access_prot_allowed().
+
+When CONFIG_DEBUG_VIRTUAL is set, __pa() calls __phys_addr(),
+which in turn calls slow_virt_to_phys() for 'high_memory'.
+Because 'high_memory' is set to (the max direct mapped virt
+addr + 1), it is not a valid virtual address. Hence,
+slow_virt_to_phys() returns 0 and hit the BUG_ON. Using
+__pa_nodebug() instead of __pa() will fix this BUG_ON.
+
+However, this code block, originally written for Pentiums and
+earlier, is no longer adequate since a 32-bit Xen guest has
+MTRRs disabled and supports ZONE_HIGHMEM. In this setup,
+this code sets UC attribute for accessing RAM in high memory
+range.
+
+Delete this code block as it has been unused for a long time.
+
+Reported-by: kernel test robot <ying.huang@linux.intel.com>
+Reviewed-by: Borislav Petkov <bp@suse.de>
+Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
+Cc: Andrew Morton <akpm@linux-foundation.org>
+Cc: David Vrabel <david.vrabel@citrix.com>
+Cc: Linus Torvalds <torvalds@linux-foundation.org>
+Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Cc: Thomas Gleixner <tglx@linutronix.de>
+Cc: xen-devel@lists.xenproject.org
+Link: http://lkml.kernel.org/r/1460403360-25441-1-git-send-email-toshi.kani@hpe.com
+Link: https://lkml.org/lkml/2016/4/1/608
+Signed-off-by: Ingo Molnar <mingo@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/mm/pat.c | 19 -------------------
+ 1 file changed, 19 deletions(-)
+
+--- a/arch/x86/mm/pat.c
++++ b/arch/x86/mm/pat.c
+@@ -777,25 +777,6 @@ int phys_mem_access_prot_allowed(struct
+ if (file->f_flags & O_DSYNC)
+ pcm = _PAGE_CACHE_MODE_UC_MINUS;
+
+-#ifdef CONFIG_X86_32
+- /*
+- * On the PPro and successors, the MTRRs are used to set
+- * memory types for physical addresses outside main memory,
+- * so blindly setting UC or PWT on those pages is wrong.
+- * For Pentiums and earlier, the surround logic should disable
+- * caching for the high addresses through the KEN pin, but
+- * we maintain the tradition of paranoia in this code.
+- */
+- if (!pat_enabled() &&
+- !(boot_cpu_has(X86_FEATURE_MTRR) ||
+- boot_cpu_has(X86_FEATURE_K6_MTRR) ||
+- boot_cpu_has(X86_FEATURE_CYRIX_ARR) ||
+- boot_cpu_has(X86_FEATURE_CENTAUR_MCR)) &&
+- (pfn << PAGE_SHIFT) >= __pa(high_memory)) {
+- pcm = _PAGE_CACHE_MODE_UC;
+- }
+-#endif
+-
+ *vma_prot = __pgprot((pgprot_val(*vma_prot) & ~_PAGE_CACHE_MASK) |
+ cachemode2protval(pcm));
+ return 1;
--- /dev/null
+From d63dcf49cf5ae5605f4d14229e3888e104f294b1 Mon Sep 17 00:00:00 2001
+From: Toshi Kani <toshi.kani@hpe.com>
+Date: Wed, 23 Mar 2016 15:41:59 -0600
+Subject: x86/mm/pat: Replace cpu_has_pat with boot_cpu_has()
+
+From: Toshi Kani <toshi.kani@hpe.com>
+
+commit d63dcf49cf5ae5605f4d14229e3888e104f294b1 upstream.
+
+Borislav Petkov suggested:
+
+ > Please use on init paths boot_cpu_has(X86_FEATURE_PAT) and on fast
+ > paths static_cpu_has(X86_FEATURE_PAT). No more of that cpu_has_XXX
+ > ugliness.
+
+Replace the use of cpu_has_pat on init paths with boot_cpu_has().
+
+Suggested-by: Borislav Petkov <bp@suse.de>
+Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
+Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
+Cc: Andrew Morton <akpm@linux-foundation.org>
+Cc: Andy Lutomirski <luto@amacapital.net>
+Cc: Borislav Petkov <bp@alien8.de>
+Cc: Brian Gerst <brgerst@gmail.com>
+Cc: Denys Vlasenko <dvlasenk@redhat.com>
+Cc: H. Peter Anvin <hpa@zytor.com>
+Cc: Juergen Gross <jgross@suse.com>
+Cc: Linus Torvalds <torvalds@linux-foundation.org>
+Cc: Luis R. Rodriguez <mcgrof@suse.com>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Cc: Robert Elliott <elliott@hpe.com>
+Cc: Toshi Kani <toshi.kani@hp.com>
+Cc: konrad.wilk@oracle.com
+Cc: paul.gortmaker@windriver.com
+Cc: xen-devel@lists.xenproject.org
+Link: http://lkml.kernel.org/r/1458769323-24491-4-git-send-email-toshi.kani@hpe.com
+Signed-off-by: Ingo Molnar <mingo@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/mm/pat.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/arch/x86/mm/pat.c
++++ b/arch/x86/mm/pat.c
+@@ -212,7 +212,7 @@ static void pat_bsp_init(u64 pat)
+ {
+ u64 tmp_pat;
+
+- if (!cpu_has_pat) {
++ if (!boot_cpu_has(X86_FEATURE_PAT)) {
+ pat_disable("PAT not supported by CPU.");
+ return;
+ }
+@@ -230,7 +230,7 @@ static void pat_bsp_init(u64 pat)
+
+ static void pat_ap_init(u64 pat)
+ {
+- if (!cpu_has_pat) {
++ if (!boot_cpu_has(X86_FEATURE_PAT)) {
+ /*
+ * If this happens we are on a secondary CPU, but switched to
+ * PAT on the boot CPU. We have no way to undo PAT.
--- /dev/null
+From ad025a73f0e9344ac73ffe1b74c184033e08e7d5 Mon Sep 17 00:00:00 2001
+From: Toshi Kani <toshi.kani@hpe.com>
+Date: Wed, 23 Mar 2016 15:42:01 -0600
+Subject: x86/mtrr: Fix PAT init handling when MTRR is disabled
+
+From: Toshi Kani <toshi.kani@hpe.com>
+
+commit ad025a73f0e9344ac73ffe1b74c184033e08e7d5 upstream.
+
+get_mtrr_state() calls pat_init() on BSP even if MTRR is disabled.
+This results in calling pat_init() on BSP only since APs do not call
+pat_init() when MTRR is disabled. This inconsistency between BSP
+and APs leads to undefined behavior.
+
+Make BSP's calling condition to pat_init() consistent with AP's,
+mtrr_ap_init() and mtrr_aps_init().
+
+Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
+Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
+Cc: Andrew Morton <akpm@linux-foundation.org>
+Cc: Andy Lutomirski <luto@amacapital.net>
+Cc: Borislav Petkov <bp@alien8.de>
+Cc: Borislav Petkov <bp@suse.de>
+Cc: Brian Gerst <brgerst@gmail.com>
+Cc: Denys Vlasenko <dvlasenk@redhat.com>
+Cc: H. Peter Anvin <hpa@zytor.com>
+Cc: Juergen Gross <jgross@suse.com>
+Cc: Linus Torvalds <torvalds@linux-foundation.org>
+Cc: Luis R. Rodriguez <mcgrof@suse.com>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Cc: Toshi Kani <toshi.kani@hp.com>
+Cc: elliott@hpe.com
+Cc: konrad.wilk@oracle.com
+Cc: paul.gortmaker@windriver.com
+Cc: xen-devel@lists.xenproject.org
+Link: http://lkml.kernel.org/r/1458769323-24491-6-git-send-email-toshi.kani@hpe.com
+Signed-off-by: Ingo Molnar <mingo@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/kernel/cpu/mtrr/generic.c | 24 ++++++++++++++----------
+ arch/x86/kernel/cpu/mtrr/main.c | 3 +++
+ arch/x86/kernel/cpu/mtrr/mtrr.h | 1 +
+ 3 files changed, 18 insertions(+), 10 deletions(-)
+
+--- a/arch/x86/kernel/cpu/mtrr/generic.c
++++ b/arch/x86/kernel/cpu/mtrr/generic.c
+@@ -444,11 +444,24 @@ static void __init print_mtrr_state(void
+ pr_debug("TOM2: %016llx aka %lldM\n", mtrr_tom2, mtrr_tom2>>20);
+ }
+
++/* PAT setup for BP. We need to go through sync steps here */
++void __init mtrr_bp_pat_init(void)
++{
++ unsigned long flags;
++
++ local_irq_save(flags);
++ prepare_set();
++
++ pat_init();
++
++ post_set();
++ local_irq_restore(flags);
++}
++
+ /* Grab all of the MTRR state for this CPU into *state */
+ bool __init get_mtrr_state(void)
+ {
+ struct mtrr_var_range *vrs;
+- unsigned long flags;
+ unsigned lo, dummy;
+ unsigned int i;
+
+@@ -481,15 +494,6 @@ bool __init get_mtrr_state(void)
+
+ mtrr_state_set = 1;
+
+- /* PAT setup for BP. We need to go through sync steps here */
+- local_irq_save(flags);
+- prepare_set();
+-
+- pat_init();
+-
+- post_set();
+- local_irq_restore(flags);
+-
+ return !!(mtrr_state.enabled & MTRR_STATE_MTRR_ENABLED);
+ }
+
+--- a/arch/x86/kernel/cpu/mtrr/main.c
++++ b/arch/x86/kernel/cpu/mtrr/main.c
+@@ -752,6 +752,9 @@ void __init mtrr_bp_init(void)
+ /* BIOS may override */
+ __mtrr_enabled = get_mtrr_state();
+
++ if (mtrr_enabled())
++ mtrr_bp_pat_init();
++
+ if (mtrr_cleanup(phys_addr)) {
+ changed_by_mtrr_cleanup = 1;
+ mtrr_if->set_all();
+--- a/arch/x86/kernel/cpu/mtrr/mtrr.h
++++ b/arch/x86/kernel/cpu/mtrr/mtrr.h
+@@ -52,6 +52,7 @@ void set_mtrr_prepare_save(struct set_mt
+ void fill_mtrr_var_range(unsigned int index,
+ u32 base_lo, u32 base_hi, u32 mask_lo, u32 mask_hi);
+ bool get_mtrr_state(void);
++void mtrr_bp_pat_init(void);
+
+ extern void set_mtrr_ops(const struct mtrr_ops *ops);
+
--- /dev/null
+From edfe63ec97ed8d4496225f7ba54c9ce4207c5431 Mon Sep 17 00:00:00 2001
+From: Toshi Kani <toshi.kani@hpe.com>
+Date: Wed, 23 Mar 2016 15:42:00 -0600
+Subject: x86/mtrr: Fix Xorg crashes in Qemu sessions
+
+From: Toshi Kani <toshi.kani@hpe.com>
+
+commit edfe63ec97ed8d4496225f7ba54c9ce4207c5431 upstream.
+
+A Xorg failure on qemu32 was reported as a regression [1] caused by
+commit 9cd25aac1f44 ("x86/mm/pat: Emulate PAT when it is disabled").
+
+This patch fixes the Xorg crash.
+
+Negative effects of this regression were the following two failures [2]
+in Xorg on QEMU with QEMU CPU model "qemu32" (-cpu qemu32), which were
+triggered by the fact that its virtual CPU does not support MTRRs.
+
+ #1. copy_process() failed in the check in reserve_pfn_range()
+
+ copy_process
+ copy_mm
+ dup_mm
+ dup_mmap
+ copy_page_range
+ track_pfn_copy
+ reserve_pfn_range
+
+ A WC map request was tracked as WC in memtype, which set a PTE as
+ UC (pgprot) per __cachemode2pte_tbl[]. This led to this error in
+ reserve_pfn_range() called from track_pfn_copy(), which obtained
+ a pgprot from a PTE. It converts pgprot to page_cache_mode, which
+ does not necessarily result in the original page_cache_mode since
+ __cachemode2pte_tbl[] redirects multiple types to UC.
+
+ #2. error path in copy_process() then hit WARN_ON_ONCE in
+ untrack_pfn().
+
+ x86/PAT: Xorg:509 map pfn expected mapping type uncached-
+ minus for [mem 0xfd000000-0xfdffffff], got write-combining
+ Call Trace:
+ dump_stack
+ warn_slowpath_common
+ ? untrack_pfn
+ ? untrack_pfn
+ warn_slowpath_null
+ untrack_pfn
+ ? __kunmap_atomic
+ unmap_single_vma
+ ? pagevec_move_tail_fn
+ unmap_vmas
+ exit_mmap
+ mmput
+ copy_process.part.47
+ _do_fork
+ SyS_clone
+ do_syscall_32_irqs_on
+ entry_INT80_32
+
+These negative effects are caused by two separate bugs, but they
+can be addressed in separate patches. Fixing the pat_init() issue
+described below addresses the root cause, and avoids Xorg to hit
+these cases.
+
+When the CPU does not support MTRRs, MTRR does not call pat_init(),
+which leaves PAT enabled without initializing PAT. This pat_init()
+issue is a long-standing issue, but manifested as issue #1 (and then
+hit issue #2) with the above-mentioned commit because the memtype
+now tracks cache attribute with 'page_cache_mode'.
+
+This pat_init() issue existed before the commit, but we used pgprot
+in memtype. Hence, we did not have issue #1 before. But WC request
+resulted in WT in effect because WC pgrot is actually WT when PAT
+is not initialized. This is not how it was designed to work. When
+PAT is set to disable properly, WC is converted to UC. The use of
+WT can result in a system crash if the target range does not support
+WT. Fortunately, nobody ran into such issue before.
+
+To fix this pat_init() issue, PAT code has been enhanced to provide
+pat_disable() interface. Call this interface when MTRRs are disabled.
+By setting PAT to disable properly, PAT bypasses the memtype check,
+and avoids issue #1.
+
+ [1]: https://lkml.org/lkml/2016/3/3/828
+ [2]: https://lkml.org/lkml/2016/3/4/775
+
+Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
+Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
+Cc: Andrew Morton <akpm@linux-foundation.org>
+Cc: Andy Lutomirski <luto@amacapital.net>
+Cc: Borislav Petkov <bp@alien8.de>
+Cc: Borislav Petkov <bp@suse.de>
+Cc: Brian Gerst <brgerst@gmail.com>
+Cc: Denys Vlasenko <dvlasenk@redhat.com>
+Cc: H. Peter Anvin <hpa@zytor.com>
+Cc: Juergen Gross <jgross@suse.com>
+Cc: Linus Torvalds <torvalds@linux-foundation.org>
+Cc: Luis R. Rodriguez <mcgrof@suse.com>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Cc: Toshi Kani <toshi.kani@hp.com>
+Cc: elliott@hpe.com
+Cc: konrad.wilk@oracle.com
+Cc: paul.gortmaker@windriver.com
+Cc: xen-devel@lists.xenproject.org
+Link: http://lkml.kernel.org/r/1458769323-24491-5-git-send-email-toshi.kani@hpe.com
+Signed-off-by: Ingo Molnar <mingo@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/include/asm/mtrr.h | 6 +++++-
+ arch/x86/kernel/cpu/mtrr/main.c | 10 +++++++++-
+ 2 files changed, 14 insertions(+), 2 deletions(-)
+
+--- a/arch/x86/include/asm/mtrr.h
++++ b/arch/x86/include/asm/mtrr.h
+@@ -24,6 +24,7 @@
+ #define _ASM_X86_MTRR_H
+
+ #include <uapi/asm/mtrr.h>
++#include <asm/pat.h>
+
+
+ /*
+@@ -83,9 +84,12 @@ static inline int mtrr_trim_uncached_mem
+ static inline void mtrr_centaur_report_mcr(int mcr, u32 lo, u32 hi)
+ {
+ }
++static inline void mtrr_bp_init(void)
++{
++ pat_disable("MTRRs disabled, skipping PAT initialization too.");
++}
+
+ #define mtrr_ap_init() do {} while (0)
+-#define mtrr_bp_init() do {} while (0)
+ #define set_mtrr_aps_delayed_init() do {} while (0)
+ #define mtrr_aps_init() do {} while (0)
+ #define mtrr_bp_restore() do {} while (0)
+--- a/arch/x86/kernel/cpu/mtrr/main.c
++++ b/arch/x86/kernel/cpu/mtrr/main.c
+@@ -759,8 +759,16 @@ void __init mtrr_bp_init(void)
+ }
+ }
+
+- if (!mtrr_enabled())
++ if (!mtrr_enabled()) {
+ pr_info("MTRR: Disabled\n");
++
++ /*
++ * PAT initialization relies on MTRR's rendezvous handler.
++ * Skip PAT init until the handler can initialize both
++ * features independently.
++ */
++ pat_disable("MTRRs disabled, skipping PAT initialization too.");
++ }
+ }
+
+ void mtrr_ap_init(void)
--- /dev/null
+From b6350c21cfe8aa9d65e189509a23c0ea4b8362c2 Mon Sep 17 00:00:00 2001
+From: Toshi Kani <toshi.kani@hpe.com>
+Date: Wed, 23 Mar 2016 15:42:03 -0600
+Subject: x86/pat: Document the PAT initialization sequence
+
+From: Toshi Kani <toshi.kani@hpe.com>
+
+commit b6350c21cfe8aa9d65e189509a23c0ea4b8362c2 upstream.
+
+Update PAT documentation to describe how PAT is initialized under
+various configurations.
+
+Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
+Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
+Cc: Andrew Morton <akpm@linux-foundation.org>
+Cc: Andy Lutomirski <luto@amacapital.net>
+Cc: Borislav Petkov <bp@alien8.de>
+Cc: Borislav Petkov <bp@suse.de>
+Cc: Brian Gerst <brgerst@gmail.com>
+Cc: Denys Vlasenko <dvlasenk@redhat.com>
+Cc: H. Peter Anvin <hpa@zytor.com>
+Cc: Juergen Gross <jgross@suse.com>
+Cc: Linus Torvalds <torvalds@linux-foundation.org>
+Cc: Luis R. Rodriguez <mcgrof@suse.com>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Cc: Toshi Kani <toshi.kani@hp.com>
+Cc: elliott@hpe.com
+Cc: konrad.wilk@oracle.com
+Cc: paul.gortmaker@windriver.com
+Cc: xen-devel@lists.xenproject.org
+Link: http://lkml.kernel.org/r/1458769323-24491-8-git-send-email-toshi.kani@hpe.com
+Signed-off-by: Ingo Molnar <mingo@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ Documentation/x86/pat.txt | 32 ++++++++++++++++++++++++++++++++
+ 1 file changed, 32 insertions(+)
+
+--- a/Documentation/x86/pat.txt
++++ b/Documentation/x86/pat.txt
+@@ -196,3 +196,35 @@ Another, more verbose way of getting PAT
+ "debugpat" boot parameter. With this parameter, various debug messages are
+ printed to dmesg log.
+
++PAT Initialization
++------------------
++
++The following table describes how PAT is initialized under various
++configurations. The PAT MSR must be updated by Linux in order to support WC
++and WT attributes. Otherwise, the PAT MSR has the value programmed in it
++by the firmware. Note, Xen enables WC attribute in the PAT MSR for guests.
++
++ MTRR PAT Call Sequence PAT State PAT MSR
++ =========================================================
++ E E MTRR -> PAT init Enabled OS
++ E D MTRR -> PAT init Disabled -
++ D E MTRR -> PAT disable Disabled BIOS
++ D D MTRR -> PAT disable Disabled -
++ - np/E PAT -> PAT disable Disabled BIOS
++ - np/D PAT -> PAT disable Disabled -
++ E !P/E MTRR -> PAT init Disabled BIOS
++ D !P/E MTRR -> PAT disable Disabled BIOS
++ !M !P/E MTRR stub -> PAT disable Disabled BIOS
++
++ Legend
++ ------------------------------------------------
++ E Feature enabled in CPU
++ D Feature disabled/unsupported in CPU
++ np "nopat" boot option specified
++ !P CONFIG_X86_PAT option unset
++ !M CONFIG_MTRR option unset
++ Enabled PAT state set to enabled
++ Disabled PAT state set to disabled
++ OS PAT initializes PAT MSR with OS setting
++ BIOS PAT keeps PAT MSR with BIOS setting
++
--- /dev/null
+From 88ba281108ed0c25c9d292b48bd3f272fcb90dd0 Mon Sep 17 00:00:00 2001
+From: Toshi Kani <toshi.kani@hpe.com>
+Date: Wed, 23 Mar 2016 15:42:02 -0600
+Subject: x86/xen, pat: Remove PAT table init code from Xen
+
+From: Toshi Kani <toshi.kani@hpe.com>
+
+commit 88ba281108ed0c25c9d292b48bd3f272fcb90dd0 upstream.
+
+Xen supports PAT without MTRRs for its guests. In order to
+enable WC attribute, it was necessary for xen_start_kernel()
+to call pat_init_cache_modes() to update PAT table before
+starting guest kernel.
+
+Now that the kernel initializes PAT table to the BIOS handoff
+state when MTRR is disabled, this Xen-specific PAT init code
+is no longer necessary. Delete it from xen_start_kernel().
+
+Also change __init_cache_modes() to a static function since
+PAT table should not be tweaked by other modules.
+
+Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
+Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
+Acked-by: Juergen Gross <jgross@suse.com>
+Cc: Andrew Morton <akpm@linux-foundation.org>
+Cc: Andy Lutomirski <luto@amacapital.net>
+Cc: Borislav Petkov <bp@alien8.de>
+Cc: Borislav Petkov <bp@suse.de>
+Cc: Brian Gerst <brgerst@gmail.com>
+Cc: Denys Vlasenko <dvlasenk@redhat.com>
+Cc: H. Peter Anvin <hpa@zytor.com>
+Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
+Cc: Linus Torvalds <torvalds@linux-foundation.org>
+Cc: Luis R. Rodriguez <mcgrof@suse.com>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Cc: Toshi Kani <toshi.kani@hp.com>
+Cc: elliott@hpe.com
+Cc: paul.gortmaker@windriver.com
+Cc: xen-devel@lists.xenproject.org
+Link: http://lkml.kernel.org/r/1458769323-24491-7-git-send-email-toshi.kani@hpe.com
+Signed-off-by: Ingo Molnar <mingo@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/include/asm/pat.h | 1 -
+ arch/x86/mm/pat.c | 2 +-
+ arch/x86/xen/enlighten.c | 9 ---------
+ 3 files changed, 1 insertion(+), 11 deletions(-)
+
+--- a/arch/x86/include/asm/pat.h
++++ b/arch/x86/include/asm/pat.h
+@@ -7,7 +7,6 @@
+ bool pat_enabled(void);
+ void pat_disable(const char *reason);
+ extern void pat_init(void);
+-void __init_cache_modes(u64);
+
+ extern int reserve_memtype(u64 start, u64 end,
+ enum page_cache_mode req_pcm, enum page_cache_mode *ret_pcm);
+--- a/arch/x86/mm/pat.c
++++ b/arch/x86/mm/pat.c
+@@ -191,7 +191,7 @@ static enum page_cache_mode pat_get_cach
+ * configuration.
+ * Using lower indices is preferred, so we start with highest index.
+ */
+-void __init_cache_modes(u64 pat)
++static void __init_cache_modes(u64 pat)
+ {
+ enum page_cache_mode cache;
+ char pat_msg[33];
+--- a/arch/x86/xen/enlighten.c
++++ b/arch/x86/xen/enlighten.c
+@@ -74,7 +74,6 @@
+ #include <asm/mach_traps.h>
+ #include <asm/mwait.h>
+ #include <asm/pci_x86.h>
+-#include <asm/pat.h>
+ #include <asm/cpu.h>
+
+ #ifdef CONFIG_ACPI
+@@ -1519,7 +1518,6 @@ asmlinkage __visible void __init xen_sta
+ {
+ struct physdev_set_iopl set_iopl;
+ unsigned long initrd_start = 0;
+- u64 pat;
+ int rc;
+
+ if (!xen_start_info)
+@@ -1627,13 +1625,6 @@ asmlinkage __visible void __init xen_sta
+ xen_start_info->nr_pages);
+ xen_reserve_special_pages();
+
+- /*
+- * Modify the cache mode translation tables to match Xen's PAT
+- * configuration.
+- */
+- rdmsrl(MSR_IA32_CR_PAT, pat);
+- __init_cache_modes(pat);
+-
+ /* keep using Xen gdt for now; no urgent need to change it */
+
+ #ifdef CONFIG_X86_32
projects / thirdparty / kernel / stable-queue.git / commitdiff
