--- /dev/null
+From e09070c51b280567695022237e57c428e548b355 Mon Sep 17 00:00:00 2001
+From: Hans de Goede <hdegoede@redhat.com>
+Date: Fri, 16 Mar 2018 21:28:07 +0100
+Subject: Bluetooth: hci_bcm: Add irq_polarity module option
+
+From: Hans de Goede <hdegoede@redhat.com>
+
+commit e09070c51b280567695022237e57c428e548b355 upstream.
+
+Add irq_polarity module option for easier troubleshooting of irq-polarity
+issues.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Hans de Goede <hdegoede@redhat.com>
+Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/bluetooth/hci_bcm.c | 20 +++++++++++++++-----
+ 1 file changed, 15 insertions(+), 5 deletions(-)
+
+--- a/drivers/bluetooth/hci_bcm.c
++++ b/drivers/bluetooth/hci_bcm.c
+@@ -126,6 +126,10 @@ struct bcm_data {
+ static DEFINE_MUTEX(bcm_device_lock);
+ static LIST_HEAD(bcm_device_list);
+
++static int irq_polarity = -1;
++module_param(irq_polarity, int, 0444);
++MODULE_PARM_DESC(irq_polarity, "IRQ polarity 0: active-high 1: active-low");
++
+ static inline void host_set_baudrate(struct hci_uart *hu, unsigned int speed)
+ {
+ if (hu->serdev)
+@@ -975,11 +979,17 @@ static int bcm_acpi_probe(struct bcm_dev
+ }
+ acpi_dev_free_resource_list(&resources);
+
+- dmi_id = dmi_first_match(bcm_active_low_irq_dmi_table);
+- if (dmi_id) {
+- dev_warn(dev->dev, "%s: Overwriting IRQ polarity to active low",
+- dmi_id->ident);
+- dev->irq_active_low = true;
++ if (irq_polarity != -1) {
++ dev->irq_active_low = irq_polarity;
++ dev_warn(dev->dev, "Overwriting IRQ polarity to active %s by module-param\n",
++ dev->irq_active_low ? "low" : "high");
++ } else {
++ dmi_id = dmi_first_match(bcm_active_low_irq_dmi_table);
++ if (dmi_id) {
++ dev_warn(dev->dev, "%s: Overwriting IRQ polarity to active low",
++ dmi_id->ident);
++ dev->irq_active_low = true;
++ }
+ }
+
+ return 0;
--- /dev/null
+From bbcc328561040292f7d6796954d478e4a2335e6f Mon Sep 17 00:00:00 2001
+From: Gregory CLEMENT <gregory.clement@bootlin.com>
+Date: Wed, 4 Apr 2018 16:44:44 +0200
+Subject: cpufreq: armada-37xx: Fix clock leak
+
+From: Gregory CLEMENT <gregory.clement@bootlin.com>
+
+commit bbcc328561040292f7d6796954d478e4a2335e6f upstream.
+
+There was no clk_put() balancing the clk_get(). This commit fixes it.
+
+Fixes: 92ce45fb875d (cpufreq: Add DVFS support for Armada 37xx)
+Cc: 4.16+ <stable@vger.kernel.org> # 4.16+
+Reported-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
+Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
+Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/cpufreq/armada-37xx-cpufreq.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/drivers/cpufreq/armada-37xx-cpufreq.c
++++ b/drivers/cpufreq/armada-37xx-cpufreq.c
+@@ -202,6 +202,7 @@ static int __init armada37xx_cpufreq_dri
+ cur_frequency = clk_get_rate(clk);
+ if (!cur_frequency) {
+ dev_err(cpu_dev, "Failed to get clock rate for CPU\n");
++ clk_put(clk);
+ return -EINVAL;
+ }
+
+@@ -210,6 +211,7 @@ static int __init armada37xx_cpufreq_dri
+ return -EINVAL;
+
+ armada37xx_cpufreq_dvfs_setup(nb_pm_base, clk, dvfs->divider);
++ clk_put(clk);
+
+ for (load_lvl = ARMADA_37XX_DVFS_LOAD_0; load_lvl < LOAD_LEVEL_NR;
+ load_lvl++) {
--- /dev/null
+From 3d41386d556db9f720e00de3e11e45f39cb5071c Mon Sep 17 00:00:00 2001
+From: George Cherian <george.cherian@cavium.com>
+Date: Fri, 23 Mar 2018 03:30:31 -0700
+Subject: cpufreq: CPPC: Use transition_delay_us depending transition_latency
+
+From: George Cherian <george.cherian@cavium.com>
+
+commit 3d41386d556db9f720e00de3e11e45f39cb5071c upstream.
+
+With commit e948bc8fbee0 (cpufreq: Cap the default transition delay
+value to 10 ms) the cpufreq was not honouring the delay passed via
+ACPI (PCCT). Due to which on ARM based platforms using CPPC the
+cpufreq governor tries to change the frequency of CPUs faster than
+expected.
+
+This leads to continuous error messages like the following.
+" ACPI CPPC: PCC check channel failed. Status=0 "
+
+Earlier (without above commit) the default transition delay was
+taken form the value passed from PCCT. Use the same value provided
+by PCCT to set the transition_delay_us.
+
+Fixes: e948bc8fbee0 (cpufreq: Cap the default transition delay value to 10 ms)
+Signed-off-by: George Cherian <george.cherian@cavium.com>
+Cc: 4.14+ <stable@vger.kernel.org> # 4.14+
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/cpufreq/cppc_cpufreq.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/drivers/cpufreq/cppc_cpufreq.c
++++ b/drivers/cpufreq/cppc_cpufreq.c
+@@ -20,6 +20,7 @@
+ #include <linux/cpu.h>
+ #include <linux/cpufreq.h>
+ #include <linux/dmi.h>
++#include <linux/time.h>
+ #include <linux/vmalloc.h>
+
+ #include <asm/unaligned.h>
+@@ -162,6 +163,8 @@ static int cppc_cpufreq_cpu_init(struct
+ policy->cpuinfo.max_freq = cppc_dmi_max_khz;
+
+ policy->cpuinfo.transition_latency = cppc_get_transition_latency(cpu_num);
++ policy->transition_delay_us = cppc_get_transition_latency(cpu_num) /
++ NSEC_PER_USEC;
+ policy->shared_type = cpu->shared_type;
+
+ if (policy->shared_type == CPUFREQ_SHARED_TYPE_ANY)
--- /dev/null
+From 9ad553abe66f8be3f4755e9fa0a6ba137ce76341 Mon Sep 17 00:00:00 2001
+From: Andrew Morton <akpm@linux-foundation.org>
+Date: Tue, 10 Apr 2018 16:34:41 -0700
+Subject: fs/reiserfs/journal.c: add missing resierfs_warning() arg
+
+From: Andrew Morton <akpm@linux-foundation.org>
+
+commit 9ad553abe66f8be3f4755e9fa0a6ba137ce76341 upstream.
+
+One use of the reiserfs_warning() macro in journal_init_dev() is missing
+a parameter, causing the following warning:
+
+ REISERFS warning (device loop0): journal_init_dev: Cannot open '%s': %i journal_init_dev:
+
+This also causes a WARN_ONCE() warning in the vsprintf code, and then a
+panic if panic_on_warn is set.
+
+ Please remove unsupported %/ in format string
+ WARNING: CPU: 1 PID: 4480 at lib/vsprintf.c:2138 format_decode+0x77f/0x830 lib/vsprintf.c:2138
+ Kernel panic - not syncing: panic_on_warn set ...
+
+Just add another string argument to the macro invocation.
+
+Addresses https://syzkaller.appspot.com/bug?id=0627d4551fdc39bf1ef5d82cd9eef587047f7718
+
+Link: http://lkml.kernel.org/r/d678ebe1-6f54-8090-df4c-b9affad62293@infradead.org
+Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
+Reported-by: <syzbot+6bd77b88c1977c03f584@syzkaller.appspotmail.com>
+Tested-by: Randy Dunlap <rdunlap@infradead.org>
+Acked-by: Jeff Mahoney <jeffm@suse.com>
+Cc: Alexander Viro <viro@zeniv.linux.org.uk>
+Cc: Jan Kara <jack@suse.com>
+Cc: <stable@vger.kernel.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>
+
+---
+ fs/reiserfs/journal.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/fs/reiserfs/journal.c
++++ b/fs/reiserfs/journal.c
+@@ -2643,7 +2643,7 @@ static int journal_init_dev(struct super
+ if (IS_ERR(journal->j_dev_bd)) {
+ result = PTR_ERR(journal->j_dev_bd);
+ journal->j_dev_bd = NULL;
+- reiserfs_warning(super,
++ reiserfs_warning(super, "sh-457",
+ "journal_init_dev: Cannot open '%s': %i",
+ jdev_name, result);
+ return result;
--- /dev/null
+From 3f05317d9889ab75c7190dcd39491d2a97921984 Mon Sep 17 00:00:00 2001
+From: Eric Biggers <ebiggers@google.com>
+Date: Fri, 13 Apr 2018 15:35:30 -0700
+Subject: ipc/shm: fix use-after-free of shm file via remap_file_pages()
+
+From: Eric Biggers <ebiggers@google.com>
+
+commit 3f05317d9889ab75c7190dcd39491d2a97921984 upstream.
+
+syzbot reported a use-after-free of shm_file_data(file)->file->f_op in
+shm_get_unmapped_area(), called via sys_remap_file_pages().
+
+Unfortunately it couldn't generate a reproducer, but I found a bug which
+I think caused it. When remap_file_pages() is passed a full System V
+shared memory segment, the memory is first unmapped, then a new map is
+created using the ->vm_file. Between these steps, the shm ID can be
+removed and reused for a new shm segment. But, shm_mmap() only checks
+whether the ID is currently valid before calling the underlying file's
+->mmap(); it doesn't check whether it was reused. Thus it can use the
+wrong underlying file, one that was already freed.
+
+Fix this by making the "outer" shm file (the one that gets put in
+->vm_file) hold a reference to the real shm file, and by making
+__shm_open() require that the file associated with the shm ID matches
+the one associated with the "outer" file.
+
+Taking the reference to the real shm file is needed to fully solve the
+problem, since otherwise sfd->file could point to a freed file, which
+then could be reallocated for the reused shm ID, causing the wrong shm
+segment to be mapped (and without the required permission checks).
+
+Commit 1ac0b6dec656 ("ipc/shm: handle removed segments gracefully in
+shm_mmap()") almost fixed this bug, but it didn't go far enough because
+it didn't consider the case where the shm ID is reused.
+
+The following program usually reproduces this bug:
+
+ #include <stdlib.h>
+ #include <sys/shm.h>
+ #include <sys/syscall.h>
+ #include <unistd.h>
+
+ int main()
+ {
+ int is_parent = (fork() != 0);
+ srand(getpid());
+ for (;;) {
+ int id = shmget(0xF00F, 4096, IPC_CREAT|0700);
+ if (is_parent) {
+ void *addr = shmat(id, NULL, 0);
+ usleep(rand() % 50);
+ while (!syscall(__NR_remap_file_pages, addr, 4096, 0, 0, 0));
+ } else {
+ usleep(rand() % 50);
+ shmctl(id, IPC_RMID, NULL);
+ }
+ }
+ }
+
+It causes the following NULL pointer dereference due to a 'struct file'
+being used while it's being freed. (I couldn't actually get a KASAN
+use-after-free splat like in the syzbot report. But I think it's
+possible with this bug; it would just take a more extraordinary race...)
+
+ BUG: unable to handle kernel NULL pointer dereference at 0000000000000058
+ PGD 0 P4D 0
+ Oops: 0000 [#1] SMP NOPTI
+ CPU: 9 PID: 258 Comm: syz_ipc Not tainted 4.16.0-05140-gf8cf2f16a7c95 #189
+ Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-20171110_100015-anatol 04/01/2014
+ RIP: 0010:d_inode include/linux/dcache.h:519 [inline]
+ RIP: 0010:touch_atime+0x25/0xd0 fs/inode.c:1724
+ [...]
+ Call Trace:
+ file_accessed include/linux/fs.h:2063 [inline]
+ shmem_mmap+0x25/0x40 mm/shmem.c:2149
+ call_mmap include/linux/fs.h:1789 [inline]
+ shm_mmap+0x34/0x80 ipc/shm.c:465
+ call_mmap include/linux/fs.h:1789 [inline]
+ mmap_region+0x309/0x5b0 mm/mmap.c:1712
+ do_mmap+0x294/0x4a0 mm/mmap.c:1483
+ do_mmap_pgoff include/linux/mm.h:2235 [inline]
+ SYSC_remap_file_pages mm/mmap.c:2853 [inline]
+ SyS_remap_file_pages+0x232/0x310 mm/mmap.c:2769
+ do_syscall_64+0x64/0x1a0 arch/x86/entry/common.c:287
+ entry_SYSCALL_64_after_hwframe+0x42/0xb7
+
+[ebiggers@google.com: add comment]
+ Link: http://lkml.kernel.org/r/20180410192850.235835-1-ebiggers3@gmail.com
+Link: http://lkml.kernel.org/r/20180409043039.28915-1-ebiggers3@gmail.com
+Reported-by: syzbot+d11f321e7f1923157eac80aa990b446596f46439@syzkaller.appspotmail.com
+Fixes: c8d78c1823f4 ("mm: replace remap_file_pages() syscall with emulation")
+Signed-off-by: Eric Biggers <ebiggers@google.com>
+Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
+Acked-by: Davidlohr Bueso <dbueso@suse.de>
+Cc: Manfred Spraul <manfred@colorfullife.com>
+Cc: "Eric W . Biederman" <ebiederm@xmission.com>
+Cc: <stable@vger.kernel.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>
+
+---
+ ipc/shm.c | 23 ++++++++++++++++++++---
+ 1 file changed, 20 insertions(+), 3 deletions(-)
+
+--- a/ipc/shm.c
++++ b/ipc/shm.c
+@@ -203,6 +203,12 @@ static int __shm_open(struct vm_area_str
+ if (IS_ERR(shp))
+ return PTR_ERR(shp);
+
++ if (shp->shm_file != sfd->file) {
++ /* ID was reused */
++ shm_unlock(shp);
++ return -EINVAL;
++ }
++
+ shp->shm_atim = ktime_get_real_seconds();
+ shp->shm_lprid = task_tgid_vnr(current);
+ shp->shm_nattch++;
+@@ -431,8 +437,9 @@ static int shm_mmap(struct file *file, s
+ int ret;
+
+ /*
+- * In case of remap_file_pages() emulation, the file can represent
+- * removed IPC ID: propogate shm_lock() error to caller.
++ * In case of remap_file_pages() emulation, the file can represent an
++ * IPC ID that was removed, and possibly even reused by another shm
++ * segment already. Propagate this case as an error to caller.
+ */
+ ret = __shm_open(vma);
+ if (ret)
+@@ -456,6 +463,7 @@ static int shm_release(struct inode *ino
+ struct shm_file_data *sfd = shm_file_data(file);
+
+ put_ipc_ns(sfd->ns);
++ fput(sfd->file);
+ shm_file_data(file) = NULL;
+ kfree(sfd);
+ return 0;
+@@ -1402,7 +1410,16 @@ long do_shmat(int shmid, char __user *sh
+ file->f_mapping = shp->shm_file->f_mapping;
+ sfd->id = shp->shm_perm.id;
+ sfd->ns = get_ipc_ns(ns);
+- sfd->file = shp->shm_file;
++ /*
++ * We need to take a reference to the real shm file to prevent the
++ * pointer from becoming stale in cases where the lifetime of the outer
++ * file extends beyond that of the shm segment. It's not usually
++ * possible, but it can happen during remap_file_pages() emulation as
++ * that unmaps the memory, then does ->mmap() via file reference only.
++ * We'll deny the ->mmap() if the shm segment was since removed, but to
++ * detect shm ID reuse we need to compare the file pointers.
++ */
++ sfd->file = get_file(shp->shm_file);
+ sfd->vm_ops = NULL;
+
+ err = security_mmap_file(file, prot, flags);
--- /dev/null
+From b28b08de436a638c82d0cf3dcdbdbad055baf1fc Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Glisse?= <jglisse@redhat.com>
+Date: Tue, 10 Apr 2018 16:28:15 -0700
+Subject: mm/hmm: fix header file if/else/endif maze
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Jérôme Glisse <jglisse@redhat.com>
+
+commit b28b08de436a638c82d0cf3dcdbdbad055baf1fc upstream.
+
+The #if/#else/#endif for IS_ENABLED(CONFIG_HMM) were wrong. Because of
+this after multiple include there was multiple definition of both
+hmm_mm_init() and hmm_mm_destroy() leading to build failure if HMM was
+enabled (CONFIG_HMM set).
+
+Link: http://lkml.kernel.org/r/20180323005527.758-3-jglisse@redhat.com
+Signed-off-by: Jérôme Glisse <jglisse@redhat.com>
+Acked-by: Balbir Singh <bsingharora@gmail.com>
+Cc: Andrew Morton <akpm@linux-foundation.org>
+Cc: Ralph Campbell <rcampbell@nvidia.com>
+Cc: John Hubbard <jhubbard@nvidia.com>
+Cc: Evgeny Baskakov <ebaskakov@nvidia.com>
+Cc: <stable@vger.kernel.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>
+
+---
+ include/linux/hmm.h | 9 +--------
+ 1 file changed, 1 insertion(+), 8 deletions(-)
+
+--- a/include/linux/hmm.h
++++ b/include/linux/hmm.h
+@@ -498,23 +498,16 @@ struct hmm_device {
+ struct hmm_device *hmm_device_new(void *drvdata);
+ void hmm_device_put(struct hmm_device *hmm_device);
+ #endif /* CONFIG_DEVICE_PRIVATE || CONFIG_DEVICE_PUBLIC */
+-#endif /* IS_ENABLED(CONFIG_HMM) */
+
+ /* Below are for HMM internal use only! Not to be used by device driver! */
+-#if IS_ENABLED(CONFIG_HMM_MIRROR)
+ void hmm_mm_destroy(struct mm_struct *mm);
+
+ static inline void hmm_mm_init(struct mm_struct *mm)
+ {
+ mm->hmm = NULL;
+ }
+-#else /* IS_ENABLED(CONFIG_HMM_MIRROR) */
+-static inline void hmm_mm_destroy(struct mm_struct *mm) {}
+-static inline void hmm_mm_init(struct mm_struct *mm) {}
+-#endif /* IS_ENABLED(CONFIG_HMM_MIRROR) */
+-
+-
+ #else /* IS_ENABLED(CONFIG_HMM) */
+ static inline void hmm_mm_destroy(struct mm_struct *mm) {}
+ static inline void hmm_mm_init(struct mm_struct *mm) {}
++#endif /* IS_ENABLED(CONFIG_HMM) */
+ #endif /* LINUX_HMM_H */
--- /dev/null
+From c719547f032d4610c7a20900baacae26d0b1ff3e Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Glisse?= <jglisse@redhat.com>
+Date: Tue, 10 Apr 2018 16:28:27 -0700
+Subject: mm/hmm: hmm_pfns_bad() was accessing wrong struct
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Jérôme Glisse <jglisse@redhat.com>
+
+commit c719547f032d4610c7a20900baacae26d0b1ff3e upstream.
+
+The private field of mm_walk struct point to an hmm_vma_walk struct and
+not to the hmm_range struct desired. Fix to get proper struct pointer.
+
+Link: http://lkml.kernel.org/r/20180323005527.758-6-jglisse@redhat.com
+Signed-off-by: Jérôme Glisse <jglisse@redhat.com>
+Cc: Evgeny Baskakov <ebaskakov@nvidia.com>
+Cc: Ralph Campbell <rcampbell@nvidia.com>
+Cc: Mark Hairgrove <mhairgrove@nvidia.com>
+Cc: John Hubbard <jhubbard@nvidia.com>
+Cc: <stable@vger.kernel.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>
+
+---
+ mm/hmm.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/mm/hmm.c
++++ b/mm/hmm.c
+@@ -277,7 +277,8 @@ static int hmm_pfns_bad(unsigned long ad
+ unsigned long end,
+ struct mm_walk *walk)
+ {
+- struct hmm_range *range = walk->private;
++ struct hmm_vma_walk *hmm_vma_walk = walk->private;
++ struct hmm_range *range = hmm_vma_walk->range;
+ hmm_pfn_t *pfns = range->pfns;
+ unsigned long i;
+
--- /dev/null
+From 31286a8484a85e8b4e91ddb0f5415aee8a416827 Mon Sep 17 00:00:00 2001
+From: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
+Date: Thu, 5 Apr 2018 16:23:05 -0700
+Subject: mm: hwpoison: disable memory error handling on 1GB hugepage
+
+From: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
+
+commit 31286a8484a85e8b4e91ddb0f5415aee8a416827 upstream.
+
+Recently the following BUG was reported:
+
+ Injecting memory failure for pfn 0x3c0000 at process virtual address 0x7fe300000000
+ Memory failure: 0x3c0000: recovery action for huge page: Recovered
+ BUG: unable to handle kernel paging request at ffff8dfcc0003000
+ IP: gup_pgd_range+0x1f0/0xc20
+ PGD 17ae72067 P4D 17ae72067 PUD 0
+ Oops: 0000 [#1] SMP PTI
+ ...
+ CPU: 3 PID: 5467 Comm: hugetlb_1gb Not tainted 4.15.0-rc8-mm1-abc+ #3
+ Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.9.3-1.fc25 04/01/2014
+
+You can easily reproduce this by calling madvise(MADV_HWPOISON) twice on
+a 1GB hugepage. This happens because get_user_pages_fast() is not aware
+of a migration entry on pud that was created in the 1st madvise() event.
+
+I think that conversion to pud-aligned migration entry is working, but
+other MM code walking over page table isn't prepared for it. We need
+some time and effort to make all this work properly, so this patch
+avoids the reported bug by just disabling error handling for 1GB
+hugepage.
+
+[n-horiguchi@ah.jp.nec.com: v2]
+ Link: http://lkml.kernel.org/r/1517284444-18149-1-git-send-email-n-horiguchi@ah.jp.nec.com
+Link: http://lkml.kernel.org/r/1517207283-15769-1-git-send-email-n-horiguchi@ah.jp.nec.com
+Signed-off-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
+Acked-by: Michal Hocko <mhocko@suse.com>
+Reviewed-by: Andrew Morton <akpm@linux-foundation.org>
+Reviewed-by: Mike Kravetz <mike.kravetz@oracle.com>
+Acked-by: Punit Agrawal <punit.agrawal@arm.com>
+Tested-by: Michael Ellerman <mpe@ellerman.id.au>
+Cc: Anshuman Khandual <khandual@linux.vnet.ibm.com>
+Cc: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
+Cc: <stable@vger.kernel.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>
+
+---
+ include/linux/mm.h | 1 +
+ mm/memory-failure.c | 16 ++++++++++++++++
+ 2 files changed, 17 insertions(+)
+
+--- a/include/linux/mm.h
++++ b/include/linux/mm.h
+@@ -2604,6 +2604,7 @@ enum mf_action_page_type {
+ MF_MSG_POISONED_HUGE,
+ MF_MSG_HUGE,
+ MF_MSG_FREE_HUGE,
++ MF_MSG_NON_PMD_HUGE,
+ MF_MSG_UNMAP_FAILED,
+ MF_MSG_DIRTY_SWAPCACHE,
+ MF_MSG_CLEAN_SWAPCACHE,
+--- a/mm/memory-failure.c
++++ b/mm/memory-failure.c
+@@ -502,6 +502,7 @@ static const char * const action_page_ty
+ [MF_MSG_POISONED_HUGE] = "huge page already hardware poisoned",
+ [MF_MSG_HUGE] = "huge page",
+ [MF_MSG_FREE_HUGE] = "free huge page",
++ [MF_MSG_NON_PMD_HUGE] = "non-pmd-sized huge page",
+ [MF_MSG_UNMAP_FAILED] = "unmapping failed page",
+ [MF_MSG_DIRTY_SWAPCACHE] = "dirty swapcache page",
+ [MF_MSG_CLEAN_SWAPCACHE] = "clean swapcache page",
+@@ -1084,6 +1085,21 @@ static int memory_failure_hugetlb(unsign
+ return 0;
+ }
+
++ /*
++ * TODO: hwpoison for pud-sized hugetlb doesn't work right now, so
++ * simply disable it. In order to make it work properly, we need
++ * make sure that:
++ * - conversion of a pud that maps an error hugetlb into hwpoison
++ * entry properly works, and
++ * - other mm code walking over page table is aware of pud-aligned
++ * hwpoison entries.
++ */
++ if (huge_page_size(page_hstate(head)) > PMD_SIZE) {
++ action_result(pfn, MF_MSG_NON_PMD_HUGE, MF_IGNORED);
++ res = -EBUSY;
++ goto out;
++ }
++
+ if (!hwpoison_user_mappings(p, pfn, flags, &head)) {
+ action_result(pfn, MF_MSG_UNMAP_FAILED, MF_IGNORED);
+ res = -EBUSY;
--- /dev/null
+From a38c015f3156895b07e71d4e4414289f8a3b2745 Mon Sep 17 00:00:00 2001
+From: Claudio Imbrenda <imbrenda@linux.vnet.ibm.com>
+Date: Tue, 10 Apr 2018 16:29:41 -0700
+Subject: mm/ksm.c: fix inconsistent accounting of zero pages
+
+From: Claudio Imbrenda <imbrenda@linux.vnet.ibm.com>
+
+commit a38c015f3156895b07e71d4e4414289f8a3b2745 upstream.
+
+When using KSM with use_zero_pages, we replace anonymous pages
+containing only zeroes with actual zero pages, which are not anonymous.
+We need to do proper accounting of the mm counters, otherwise we will
+get wrong values in /proc and a BUG message in dmesg when tearing down
+the mm.
+
+Link: http://lkml.kernel.org/r/1522931274-15552-1-git-send-email-imbrenda@linux.vnet.ibm.com
+Fixes: e86c59b1b1 ("mm/ksm: improve deduplication of zero pages with colouring")
+Signed-off-by: Claudio Imbrenda <imbrenda@linux.vnet.ibm.com>
+Reviewed-by: Andrew Morton <akpm@linux-foundation.org>
+Cc: Andrea Arcangeli <aarcange@redhat.com>
+Cc: Minchan Kim <minchan@kernel.org>
+Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
+Cc: Hugh Dickins <hughd@google.com>
+Cc: Christian Borntraeger <borntraeger@de.ibm.com>
+Cc: Gerald Schaefer <gerald.schaefer@de.ibm.com>
+Cc: <stable@vger.kernel.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>
+
+---
+ mm/ksm.c | 7 +++++++
+ 1 file changed, 7 insertions(+)
+
+--- a/mm/ksm.c
++++ b/mm/ksm.c
+@@ -1131,6 +1131,13 @@ static int replace_page(struct vm_area_s
+ } else {
+ newpte = pte_mkspecial(pfn_pte(page_to_pfn(kpage),
+ vma->vm_page_prot));
++ /*
++ * We're replacing an anonymous page with a zero page, which is
++ * not anonymous. We need to do proper accounting otherwise we
++ * will get wrong values in /proc, and a BUG message in dmesg
++ * when tearing down the mm.
++ */
++ dec_mm_counter(mm, MM_ANONPAGES);
+ }
+
+ flush_cache_page(vma, addr, pte_pfn(*ptep));
--- /dev/null
+From a9f2a846f0503e7d729f552e3ccfe2279010fe94 Mon Sep 17 00:00:00 2001
+From: Vlastimil Babka <vbabka@suse.cz>
+Date: Fri, 13 Apr 2018 15:35:38 -0700
+Subject: mm, slab: reschedule cache_reap() on the same CPU
+
+From: Vlastimil Babka <vbabka@suse.cz>
+
+commit a9f2a846f0503e7d729f552e3ccfe2279010fe94 upstream.
+
+cache_reap() is initially scheduled in start_cpu_timer() via
+schedule_delayed_work_on(). But then the next iterations are scheduled
+via schedule_delayed_work(), i.e. using WORK_CPU_UNBOUND.
+
+Thus since commit ef557180447f ("workqueue: schedule WORK_CPU_UNBOUND
+work on wq_unbound_cpumask CPUs") there is no guarantee the future
+iterations will run on the originally intended cpu, although it's still
+preferred. I was able to demonstrate this with
+/sys/module/workqueue/parameters/debug_force_rr_cpu. IIUC, it may also
+happen due to migrating timers in nohz context. As a result, some cpu's
+would be calling cache_reap() more frequently and others never.
+
+This patch uses schedule_delayed_work_on() with the current cpu when
+scheduling the next iteration.
+
+Link: http://lkml.kernel.org/r/20180411070007.32225-1-vbabka@suse.cz
+Fixes: ef557180447f ("workqueue: schedule WORK_CPU_UNBOUND work on wq_unbound_cpumask CPUs")
+Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
+Acked-by: Pekka Enberg <penberg@kernel.org>
+Acked-by: Christoph Lameter <cl@linux.com>
+Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
+Cc: David Rientjes <rientjes@google.com>
+Cc: Tejun Heo <tj@kernel.org>
+Cc: Lai Jiangshan <jiangshanlai@gmail.com>
+Cc: John Stultz <john.stultz@linaro.org>
+Cc: Thomas Gleixner <tglx@linutronix.de>
+Cc: Stephen Boyd <sboyd@kernel.org>
+Cc: <stable@vger.kernel.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>
+
+---
+ mm/slab.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/mm/slab.c
++++ b/mm/slab.c
+@@ -4074,7 +4074,8 @@ next:
+ next_reap_node();
+ out:
+ /* Set up the next iteration */
+- schedule_delayed_work(work, round_jiffies_relative(REAPTIMEOUT_AC));
++ schedule_delayed_work_on(smp_processor_id(), work,
++ round_jiffies_relative(REAPTIMEOUT_AC));
+ }
+
+ void get_slabinfo(struct kmem_cache *cachep, struct slabinfo *sinfo)
--- /dev/null
+From d7119224bfe6e8efbf821a52db7da9530d790f07 Mon Sep 17 00:00:00 2001
+From: Chen-Yu Tsai <wens@csie.org>
+Date: Fri, 19 Jan 2018 17:25:41 +0800
+Subject: phy: allwinner: sun4i-usb: poll vbus changes on A23/A33 when driving VBUS
+
+From: Chen-Yu Tsai <wens@csie.org>
+
+commit d7119224bfe6e8efbf821a52db7da9530d790f07 upstream.
+
+The AXP223 PMIC, like the AXP221, does not generate VBUS change
+interrupts when N_VBUSEN is used to drive VBUS for the OTG port
+on the board.
+
+This was not noticed until recently, as most A23/A33 boards use
+a GPIO pin that does not support interrupts for OTG ID detection.
+This forces the driver to use polling. However the A33-OlinuXino
+uses a pin that does support interrupts, so the driver uses them.
+However the VBUS interrupt never fires, and the driver never gets
+to update the VBUS status. This results in musb timing out waiting
+for VBUS to rise.
+
+This was worked around for the AXP221 by resorting to polling
+changes in commit 91d96f06a760 ("phy-sun4i-usb: Add workaround for
+missing Vbus det interrupts on A31"). This patch adds the A23 and
+A33 to the list of SoCs that need the workaround.
+
+Fixes: fc1f45ed3043 ("phy-sun4i-usb: Add support for the usb-phys on the
+ sun8i-a33 SoC")
+Fixes: 123dfdbcfaf5 ("phy-sun4i-usb: Add support for the usb-phys on the
+ sun8i-a23 SoC")
+Cc: <stable@vger.kernel.org> # 4.3.x: 68dbc2ce77bb phy-sun4i-usb:
+ Use of_match_node to get model specific config data
+Cc: <stable@vger.kernel.org> # 4.3.x: 5cf700ac9d50 phy: phy-sun4i-usb:
+ Fix optional gpios failing probe
+Cc: <stable@vger.kernel.org> # 4.3.x: 04e59a0211ff phy-sun4i-usb:
+ Fix irq free conditions to match request conditions
+Cc: <stable@vger.kernel.org> # 4.3.x: 91d96f06a760 phy-sun4i-usb:
+ Add workaround for missing Vbus det interrupts on A31
+Cc: <stable@vger.kernel.org> # 4.3.x
+Signed-off-by: Chen-Yu Tsai <wens@csie.org>
+Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
+Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
+
+---
+ drivers/phy/allwinner/phy-sun4i-usb.c | 10 ++++++----
+ 1 file changed, 6 insertions(+), 4 deletions(-)
+
+--- a/drivers/phy/allwinner/phy-sun4i-usb.c
++++ b/drivers/phy/allwinner/phy-sun4i-usb.c
+@@ -410,11 +410,13 @@ static bool sun4i_usb_phy0_poll(struct s
+ return true;
+
+ /*
+- * The A31 companion pmic (axp221) does not generate vbus change
+- * interrupts when the board is driving vbus, so we must poll
++ * The A31/A23/A33 companion pmics (AXP221/AXP223) do not
++ * generate vbus change interrupts when the board is driving
++ * vbus using the N_VBUSEN pin on the pmic, so we must poll
+ * when using the pmic for vbus-det _and_ we're driving vbus.
+ */
+- if (data->cfg->type == sun6i_a31_phy &&
++ if ((data->cfg->type == sun6i_a31_phy ||
++ data->cfg->type == sun8i_a33_phy) &&
+ data->vbus_power_supply && data->phys[0].regulator_on)
+ return true;
+
+@@ -885,7 +887,7 @@ static const struct sun4i_usb_phy_cfg su
+
+ static const struct sun4i_usb_phy_cfg sun8i_a23_cfg = {
+ .num_phys = 2,
+- .type = sun4i_a10_phy,
++ .type = sun6i_a31_phy,
+ .disc_thresh = 3,
+ .phyctl_offset = REG_PHYCTL_A10,
+ .dedicated_clocks = true,
--- /dev/null
+From 60bb83b81169820c691fbfa33a6a4aef32aa4b0b Mon Sep 17 00:00:00 2001
+From: Takashi Iwai <tiwai@suse.de>
+Date: Fri, 13 Apr 2018 15:35:13 -0700
+Subject: resource: fix integer overflow at reallocation
+
+From: Takashi Iwai <tiwai@suse.de>
+
+commit 60bb83b81169820c691fbfa33a6a4aef32aa4b0b upstream.
+
+We've got a bug report indicating a kernel panic at booting on an x86-32
+system, and it turned out to be the invalid PCI resource assigned after
+reallocation. __find_resource() first aligns the resource start address
+and resets the end address with start+size-1 accordingly, then checks
+whether it's contained. Here the end address may overflow the integer,
+although resource_contains() still returns true because the function
+validates only start and end address. So this ends up with returning an
+invalid resource (start > end).
+
+There was already an attempt to cover such a problem in the commit
+47ea91b4052d ("Resource: fix wrong resource window calculation"), but
+this case is an overseen one.
+
+This patch adds the validity check of the newly calculated resource for
+avoiding the integer overflow problem.
+
+Bugzilla: http://bugzilla.opensuse.org/show_bug.cgi?id=1086739
+Link: http://lkml.kernel.org/r/s5hpo37d5l8.wl-tiwai@suse.de
+Fixes: 23c570a67448 ("resource: ability to resize an allocated resource")
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Reported-by: Michael Henders <hendersm@shaw.ca>
+Tested-by: Michael Henders <hendersm@shaw.ca>
+Reviewed-by: Andrew Morton <akpm@linux-foundation.org>
+Cc: Ram Pai <linuxram@us.ibm.com>
+Cc: Bjorn Helgaas <bhelgaas@google.com>
+Cc: <stable@vger.kernel.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>
+
+---
+ kernel/resource.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/kernel/resource.c
++++ b/kernel/resource.c
+@@ -651,7 +651,8 @@ static int __find_resource(struct resour
+ alloc.start = constraint->alignf(constraint->alignf_data, &avail,
+ size, constraint->align);
+ alloc.end = alloc.start + size - 1;
+- if (resource_contains(&avail, &alloc)) {
++ if (alloc.start <= alloc.end &&
++ resource_contains(&avail, &alloc)) {
+ new->start = alloc.start;
+ new->end = alloc.end;
+ return 0;
+bluetooth-hci_bcm-add-irq_polarity-module-option.patch
+cpufreq-cppc-use-transition_delay_us-depending-transition_latency.patch
+cpufreq-armada-37xx-fix-clock-leak.patch
+ubifs-check-ubifs_wbuf_sync-return-code.patch
+ubi-fastmap-don-t-flush-fastmap-work-on-detach.patch
+ubi-fix-error-for-write-access.patch
+ubi-reject-mlc-nand.patch
+mm-ksm.c-fix-inconsistent-accounting-of-zero-pages.patch
+mm-hmm-fix-header-file-if-else-endif-maze.patch
+mm-hmm-hmm_pfns_bad-was-accessing-wrong-struct.patch
+mm-hwpoison-disable-memory-error-handling-on-1gb-hugepage.patch
+task_struct-only-use-anon-struct-under-randstruct-plugin.patch
+fs-reiserfs-journal.c-add-missing-resierfs_warning-arg.patch
+resource-fix-integer-overflow-at-reallocation.patch
+ipc-shm-fix-use-after-free-of-shm-file-via-remap_file_pages.patch
+mm-slab-reschedule-cache_reap-on-the-same-cpu.patch
+usb-musb-gadget-misplaced-out-of-bounds-check.patch
+phy-allwinner-sun4i-usb-poll-vbus-changes-on-a23-a33-when-driving-vbus.patch
+usb-gadget-udc-core-update-usb_ep_queue-documentation.patch
--- /dev/null
+From 2cfe0d3009418a132b93d78642a8059a38fe5944 Mon Sep 17 00:00:00 2001
+From: Kees Cook <keescook@chromium.org>
+Date: Tue, 10 Apr 2018 16:32:44 -0700
+Subject: task_struct: only use anon struct under randstruct plugin
+
+From: Kees Cook <keescook@chromium.org>
+
+commit 2cfe0d3009418a132b93d78642a8059a38fe5944 upstream.
+
+The original intent for always adding the anonymous struct in
+task_struct was to make sure we had compiler coverage.
+
+However, this caused pathological padding of 40 bytes at the start of
+task_struct. Instead, move the anonymous struct to being only used when
+struct layout randomization is enabled.
+
+Link: http://lkml.kernel.org/r/20180327213609.GA2964@beast
+Fixes: 29e48ce87f1e ("task_struct: Allow randomized")
+Signed-off-by: Kees Cook <keescook@chromium.org>
+Reported-by: Peter Zijlstra <peterz@infradead.org>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Cc: Ingo Molnar <mingo@kernel.org>
+Cc: <stable@vger.kernel.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>
+
+---
+ include/linux/compiler-clang.h | 3 ---
+ include/linux/compiler-gcc.h | 12 +++---------
+ 2 files changed, 3 insertions(+), 12 deletions(-)
+
+--- a/include/linux/compiler-clang.h
++++ b/include/linux/compiler-clang.h
+@@ -17,9 +17,6 @@
+ */
+ #define __UNIQUE_ID(prefix) __PASTE(__PASTE(__UNIQUE_ID_, prefix), __COUNTER__)
+
+-#define randomized_struct_fields_start struct {
+-#define randomized_struct_fields_end };
+-
+ /* all clang versions usable with the kernel support KASAN ABI version 5 */
+ #define KASAN_ABI_VERSION 5
+
+--- a/include/linux/compiler-gcc.h
++++ b/include/linux/compiler-gcc.h
+@@ -242,6 +242,9 @@
+ #if defined(RANDSTRUCT_PLUGIN) && !defined(__CHECKER__)
+ #define __randomize_layout __attribute__((randomize_layout))
+ #define __no_randomize_layout __attribute__((no_randomize_layout))
++/* This anon struct can add padding, so only enable it under randstruct. */
++#define randomized_struct_fields_start struct {
++#define randomized_struct_fields_end } __randomize_layout;
+ #endif
+
+ #endif /* GCC_VERSION >= 40500 */
+@@ -256,15 +259,6 @@
+ */
+ #define __visible __attribute__((externally_visible))
+
+-/*
+- * RANDSTRUCT_PLUGIN wants to use an anonymous struct, but it is only
+- * possible since GCC 4.6. To provide as much build testing coverage
+- * as possible, this is used for all GCC 4.6+ builds, and not just on
+- * RANDSTRUCT_PLUGIN builds.
+- */
+-#define randomized_struct_fields_start struct {
+-#define randomized_struct_fields_end } __randomize_layout;
+-
+ #endif /* GCC_VERSION >= 40600 */
+
+
--- /dev/null
+From 29b7a6fa1ec07e8480b0d9caf635a4498a438bf4 Mon Sep 17 00:00:00 2001
+From: Richard Weinberger <richard@nod.at>
+Date: Wed, 17 Jan 2018 23:15:57 +0100
+Subject: ubi: fastmap: Don't flush fastmap work on detach
+
+From: Richard Weinberger <richard@nod.at>
+
+commit 29b7a6fa1ec07e8480b0d9caf635a4498a438bf4 upstream.
+
+At this point UBI volumes have already been free()'ed and fastmap can no
+longer access these data structures.
+
+Reported-by: Martin Townsend <mtownsend1973@gmail.com>
+Fixes: 74cdaf24004a ("UBI: Fastmap: Fix memory leaks while closing the WL sub-system")
+Cc: stable@vger.kernel.org
+Signed-off-by: Richard Weinberger <richard@nod.at>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/mtd/ubi/fastmap-wl.c | 1 -
+ 1 file changed, 1 deletion(-)
+
+--- a/drivers/mtd/ubi/fastmap-wl.c
++++ b/drivers/mtd/ubi/fastmap-wl.c
+@@ -362,7 +362,6 @@ static void ubi_fastmap_close(struct ubi
+ {
+ int i;
+
+- flush_work(&ubi->fm_work);
+ return_unused_pool_pebs(ubi, &ubi->fm_pool);
+ return_unused_pool_pebs(ubi, &ubi->fm_wl_pool);
+
--- /dev/null
+From 78a8dfbabbece22bee58ac4cb26cab10e7a19c5d Mon Sep 17 00:00:00 2001
+From: Romain Izard <romain.izard.pro@gmail.com>
+Date: Mon, 29 Jan 2018 11:18:20 +0100
+Subject: ubi: Fix error for write access
+
+From: Romain Izard <romain.izard.pro@gmail.com>
+
+commit 78a8dfbabbece22bee58ac4cb26cab10e7a19c5d upstream.
+
+When opening a device with write access, ubiblock_open returns an error
+code. Currently, this error code is -EPERM, but this is not the right
+value.
+
+The open function for other block devices returns -EROFS when opening
+read-only devices with FMODE_WRITE set. When used with dm-verity, the
+veritysetup userspace tool is expecting EROFS, and refuses to use the
+ubiblock device.
+
+Use -EROFS for ubiblock as well. As a result, veritysetup accepts the
+ubiblock device as valid.
+
+Cc: stable@vger.kernel.org
+Fixes: 9d54c8a33eec (UBI: R/O block driver on top of UBI volumes)
+Signed-off-by: Romain Izard <romain.izard.pro@gmail.com>
+Signed-off-by: Richard Weinberger <richard@nod.at>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/mtd/ubi/block.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/mtd/ubi/block.c
++++ b/drivers/mtd/ubi/block.c
+@@ -244,7 +244,7 @@ static int ubiblock_open(struct block_de
+ * in any case.
+ */
+ if (mode & FMODE_WRITE) {
+- ret = -EPERM;
++ ret = -EROFS;
+ goto out_unlock;
+ }
+
--- /dev/null
+From b5094b7f135be34630e3ea8a98fa215715d0f29d Mon Sep 17 00:00:00 2001
+From: Richard Weinberger <richard@nod.at>
+Date: Sat, 3 Mar 2018 11:45:54 +0100
+Subject: ubi: Reject MLC NAND
+
+From: Richard Weinberger <richard@nod.at>
+
+commit b5094b7f135be34630e3ea8a98fa215715d0f29d upstream.
+
+While UBI and UBIFS seem to work at first sight with MLC NAND, you will
+most likely lose all your data upon a power-cut or due to read/write
+disturb.
+In order to protect users from bad surprises, refuse to attach to MLC
+NAND.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Richard Weinberger <richard@nod.at>
+Acked-by: Boris Brezillon <boris.brezillon@bootlin.com>
+Acked-by: Artem Bityutskiy <dedekind1@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/mtd/ubi/build.c | 11 +++++++++++
+ 1 file changed, 11 insertions(+)
+
+--- a/drivers/mtd/ubi/build.c
++++ b/drivers/mtd/ubi/build.c
+@@ -854,6 +854,17 @@ int ubi_attach_mtd_dev(struct mtd_info *
+ return -EINVAL;
+ }
+
++ /*
++ * Both UBI and UBIFS have been designed for SLC NAND and NOR flashes.
++ * MLC NAND is different and needs special care, otherwise UBI or UBIFS
++ * will die soon and you will lose all your data.
++ */
++ if (mtd->type == MTD_MLCNANDFLASH) {
++ pr_err("ubi: refuse attaching mtd%d - MLC NAND is not supported\n",
++ mtd->index);
++ return -EINVAL;
++ }
++
+ if (ubi_num == UBI_DEV_NUM_AUTO) {
+ /* Search for an empty slot in the @ubi_devices array */
+ for (ubi_num = 0; ubi_num < UBI_MAX_DEVICES; ubi_num++)
--- /dev/null
+From aac17948a7ce01fb60b9ee6cf902967a47b3ce26 Mon Sep 17 00:00:00 2001
+From: Richard Weinberger <richard@nod.at>
+Date: Wed, 17 Jan 2018 19:12:42 +0100
+Subject: ubifs: Check ubifs_wbuf_sync() return code
+
+From: Richard Weinberger <richard@nod.at>
+
+commit aac17948a7ce01fb60b9ee6cf902967a47b3ce26 upstream.
+
+If ubifs_wbuf_sync() fails we must not write a master node with the
+dirty marker cleared.
+Otherwise it is possible that in case of an IO error while syncing we
+mark the filesystem as clean and UBIFS refuses to recover upon next
+mount.
+
+Cc: <stable@vger.kernel.org>
+Fixes: 1e51764a3c2a ("UBIFS: add new flash file system")
+Signed-off-by: Richard Weinberger <richard@nod.at>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/ubifs/super.c | 14 ++++++++++----
+ 1 file changed, 10 insertions(+), 4 deletions(-)
+
+--- a/fs/ubifs/super.c
++++ b/fs/ubifs/super.c
+@@ -1737,8 +1737,11 @@ static void ubifs_remount_ro(struct ubif
+
+ dbg_save_space_info(c);
+
+- for (i = 0; i < c->jhead_cnt; i++)
+- ubifs_wbuf_sync(&c->jheads[i].wbuf);
++ for (i = 0; i < c->jhead_cnt; i++) {
++ err = ubifs_wbuf_sync(&c->jheads[i].wbuf);
++ if (err)
++ ubifs_ro_mode(c, err);
++ }
+
+ c->mst_node->flags &= ~cpu_to_le32(UBIFS_MST_DIRTY);
+ c->mst_node->flags |= cpu_to_le32(UBIFS_MST_NO_ORPHS);
+@@ -1804,8 +1807,11 @@ static void ubifs_put_super(struct super
+ int err;
+
+ /* Synchronize write-buffers */
+- for (i = 0; i < c->jhead_cnt; i++)
+- ubifs_wbuf_sync(&c->jheads[i].wbuf);
++ for (i = 0; i < c->jhead_cnt; i++) {
++ err = ubifs_wbuf_sync(&c->jheads[i].wbuf);
++ if (err)
++ ubifs_ro_mode(c, err);
++ }
+
+ /*
+ * We are being cleanly unmounted which means the
--- /dev/null
+From eaa358c7790338d83bb6a31258bdc077de120414 Mon Sep 17 00:00:00 2001
+From: Felipe Balbi <felipe.balbi@linux.intel.com>
+Date: Mon, 26 Mar 2018 13:14:46 +0300
+Subject: usb: gadget: udc: core: update usb_ep_queue() documentation
+
+From: Felipe Balbi <felipe.balbi@linux.intel.com>
+
+commit eaa358c7790338d83bb6a31258bdc077de120414 upstream.
+
+Mention that ->complete() should never be called from within
+usb_ep_queue().
+
+Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
+Cc: stable <stable@vger.kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/gadget/udc/core.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/drivers/usb/gadget/udc/core.c
++++ b/drivers/usb/gadget/udc/core.c
+@@ -238,6 +238,9 @@ EXPORT_SYMBOL_GPL(usb_ep_free_request);
+ * arranges to poll once per interval, and the gadget driver usually will
+ * have queued some data to transfer at that time.
+ *
++ * Note that @req's ->complete() callback must never be called from
++ * within usb_ep_queue() as that can create deadlock situations.
++ *
+ * Returns zero, or a negative error code. Endpoints that are not enabled
+ * report errors; errors will also be
+ * reported when the usb peripheral is disconnected.
--- /dev/null
+From af6f8529098aeb0e56a68671b450cf74e7a64fcd Mon Sep 17 00:00:00 2001
+From: Heinrich Schuchardt <xypron.glpk@gmx.de>
+Date: Thu, 29 Mar 2018 10:48:28 -0500
+Subject: usb: musb: gadget: misplaced out of bounds check
+
+From: Heinrich Schuchardt <xypron.glpk@gmx.de>
+
+commit af6f8529098aeb0e56a68671b450cf74e7a64fcd upstream.
+
+musb->endpoints[] has array size MUSB_C_NUM_EPS.
+We must check array bounds before accessing the array and not afterwards.
+
+Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
+Signed-off-by: Bin Liu <b-liu@ti.com>
+Cc: stable <stable@vger.kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/musb/musb_gadget_ep0.c | 14 +++++++++-----
+ 1 file changed, 9 insertions(+), 5 deletions(-)
+
+--- a/drivers/usb/musb/musb_gadget_ep0.c
++++ b/drivers/usb/musb/musb_gadget_ep0.c
+@@ -89,15 +89,19 @@ static int service_tx_status_request(
+ }
+
+ is_in = epnum & USB_DIR_IN;
+- if (is_in) {
+- epnum &= 0x0f;
++ epnum &= 0x0f;
++ if (epnum >= MUSB_C_NUM_EPS) {
++ handled = -EINVAL;
++ break;
++ }
++
++ if (is_in)
+ ep = &musb->endpoints[epnum].ep_in;
+- } else {
++ else
+ ep = &musb->endpoints[epnum].ep_out;
+- }
+ regs = musb->endpoints[epnum].regs;
+
+- if (epnum >= MUSB_C_NUM_EPS || !ep->desc) {
++ if (!ep->desc) {
+ handled = -EINVAL;
+ break;
+ }
projects / thirdparty / kernel / stable-queue.git / commitdiff
