From: Greg Kroah-Hartman Date: Thu, 19 Apr 2018 15:30:10 +0000 (+0200) Subject: 4.16-stable patches X-Git-Tag: v4.9.95~9 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=885c8f02d439d588115fbb19b7f988c5ac5241f3;p=thirdparty%2Fkernel%2Fstable-queue.git 4.16-stable patches added patches: bluetooth-hci_bcm-add-irq_polarity-module-option.patch cpufreq-armada-37xx-fix-clock-leak.patch cpufreq-cppc-use-transition_delay_us-depending-transition_latency.patch fs-reiserfs-journal.c-add-missing-resierfs_warning-arg.patch ipc-shm-fix-use-after-free-of-shm-file-via-remap_file_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 mm-ksm.c-fix-inconsistent-accounting-of-zero-pages.patch mm-slab-reschedule-cache_reap-on-the-same-cpu.patch phy-allwinner-sun4i-usb-poll-vbus-changes-on-a23-a33-when-driving-vbus.patch resource-fix-integer-overflow-at-reallocation.patch task_struct-only-use-anon-struct-under-randstruct-plugin.patch ubi-fastmap-don-t-flush-fastmap-work-on-detach.patch ubi-fix-error-for-write-access.patch ubi-reject-mlc-nand.patch ubifs-check-ubifs_wbuf_sync-return-code.patch usb-gadget-udc-core-update-usb_ep_queue-documentation.patch usb-musb-gadget-misplaced-out-of-bounds-check.patch --- diff --git a/queue-4.16/bluetooth-hci_bcm-add-irq_polarity-module-option.patch b/queue-4.16/bluetooth-hci_bcm-add-irq_polarity-module-option.patch new file mode 100644 index 00000000000..e1bd6bdd8a4 --- /dev/null +++ b/queue-4.16/bluetooth-hci_bcm-add-irq_polarity-module-option.patch @@ -0,0 +1,57 @@ +From e09070c51b280567695022237e57c428e548b355 Mon Sep 17 00:00:00 2001 +From: Hans de Goede +Date: Fri, 16 Mar 2018 21:28:07 +0100 +Subject: Bluetooth: hci_bcm: Add irq_polarity module option + +From: Hans de Goede + +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 +Signed-off-by: Marcel Holtmann +Signed-off-by: Greg Kroah-Hartman + +--- + 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; diff --git a/queue-4.16/cpufreq-armada-37xx-fix-clock-leak.patch b/queue-4.16/cpufreq-armada-37xx-fix-clock-leak.patch new file mode 100644 index 00000000000..b4d4e28ecc4 --- /dev/null +++ b/queue-4.16/cpufreq-armada-37xx-fix-clock-leak.patch @@ -0,0 +1,41 @@ +From bbcc328561040292f7d6796954d478e4a2335e6f Mon Sep 17 00:00:00 2001 +From: Gregory CLEMENT +Date: Wed, 4 Apr 2018 16:44:44 +0200 +Subject: cpufreq: armada-37xx: Fix clock leak + +From: Gregory CLEMENT + +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+ # 4.16+ +Reported-by: Thomas Petazzoni +Signed-off-by: Gregory CLEMENT +Acked-by: Viresh Kumar +Signed-off-by: Rafael J. Wysocki +Signed-off-by: Greg Kroah-Hartman + +--- + 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++) { diff --git a/queue-4.16/cpufreq-cppc-use-transition_delay_us-depending-transition_latency.patch b/queue-4.16/cpufreq-cppc-use-transition_delay_us-depending-transition_latency.patch new file mode 100644 index 00000000000..b2c025537e5 --- /dev/null +++ b/queue-4.16/cpufreq-cppc-use-transition_delay_us-depending-transition_latency.patch @@ -0,0 +1,51 @@ +From 3d41386d556db9f720e00de3e11e45f39cb5071c Mon Sep 17 00:00:00 2001 +From: George Cherian +Date: Fri, 23 Mar 2018 03:30:31 -0700 +Subject: cpufreq: CPPC: Use transition_delay_us depending transition_latency + +From: George Cherian + +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 +Cc: 4.14+ # 4.14+ +Signed-off-by: Rafael J. Wysocki +Signed-off-by: Greg Kroah-Hartman + +--- + 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 + #include + #include ++#include + #include + + #include +@@ -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) diff --git a/queue-4.16/fs-reiserfs-journal.c-add-missing-resierfs_warning-arg.patch b/queue-4.16/fs-reiserfs-journal.c-add-missing-resierfs_warning-arg.patch new file mode 100644 index 00000000000..f913b37bba2 --- /dev/null +++ b/queue-4.16/fs-reiserfs-journal.c-add-missing-resierfs_warning-arg.patch @@ -0,0 +1,52 @@ +From 9ad553abe66f8be3f4755e9fa0a6ba137ce76341 Mon Sep 17 00:00:00 2001 +From: Andrew Morton +Date: Tue, 10 Apr 2018 16:34:41 -0700 +Subject: fs/reiserfs/journal.c: add missing resierfs_warning() arg + +From: Andrew Morton + +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 +Reported-by: +Tested-by: Randy Dunlap +Acked-by: Jeff Mahoney +Cc: Alexander Viro +Cc: Jan Kara +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + 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; diff --git a/queue-4.16/ipc-shm-fix-use-after-free-of-shm-file-via-remap_file_pages.patch b/queue-4.16/ipc-shm-fix-use-after-free-of-shm-file-via-remap_file_pages.patch new file mode 100644 index 00000000000..61cfcbab36f --- /dev/null +++ b/queue-4.16/ipc-shm-fix-use-after-free-of-shm-file-via-remap_file_pages.patch @@ -0,0 +1,158 @@ +From 3f05317d9889ab75c7190dcd39491d2a97921984 Mon Sep 17 00:00:00 2001 +From: Eric Biggers +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 + +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 + #include + #include + #include + + 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 +Acked-by: Kirill A. Shutemov +Acked-by: Davidlohr Bueso +Cc: Manfred Spraul +Cc: "Eric W . Biederman" +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + 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); diff --git a/queue-4.16/mm-hmm-fix-header-file-if-else-endif-maze.patch b/queue-4.16/mm-hmm-fix-header-file-if-else-endif-maze.patch new file mode 100644 index 00000000000..0f5801ca7fa --- /dev/null +++ b/queue-4.16/mm-hmm-fix-header-file-if-else-endif-maze.patch @@ -0,0 +1,60 @@ +From b28b08de436a638c82d0cf3dcdbdbad055baf1fc Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Glisse?= +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 + +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 +Acked-by: Balbir Singh +Cc: Andrew Morton +Cc: Ralph Campbell +Cc: John Hubbard +Cc: Evgeny Baskakov +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + 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 */ diff --git a/queue-4.16/mm-hmm-hmm_pfns_bad-was-accessing-wrong-struct.patch b/queue-4.16/mm-hmm-hmm_pfns_bad-was-accessing-wrong-struct.patch new file mode 100644 index 00000000000..89abf8dd5dc --- /dev/null +++ b/queue-4.16/mm-hmm-hmm_pfns_bad-was-accessing-wrong-struct.patch @@ -0,0 +1,42 @@ +From c719547f032d4610c7a20900baacae26d0b1ff3e Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Glisse?= +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 + +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 +Cc: Evgeny Baskakov +Cc: Ralph Campbell +Cc: Mark Hairgrove +Cc: John Hubbard +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + 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; + diff --git a/queue-4.16/mm-hwpoison-disable-memory-error-handling-on-1gb-hugepage.patch b/queue-4.16/mm-hwpoison-disable-memory-error-handling-on-1gb-hugepage.patch new file mode 100644 index 00000000000..290ca181398 --- /dev/null +++ b/queue-4.16/mm-hwpoison-disable-memory-error-handling-on-1gb-hugepage.patch @@ -0,0 +1,94 @@ +From 31286a8484a85e8b4e91ddb0f5415aee8a416827 Mon Sep 17 00:00:00 2001 +From: Naoya Horiguchi +Date: Thu, 5 Apr 2018 16:23:05 -0700 +Subject: mm: hwpoison: disable memory error handling on 1GB hugepage + +From: Naoya Horiguchi + +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 +Acked-by: Michal Hocko +Reviewed-by: Andrew Morton +Reviewed-by: Mike Kravetz +Acked-by: Punit Agrawal +Tested-by: Michael Ellerman +Cc: Anshuman Khandual +Cc: "Aneesh Kumar K.V" +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + 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; diff --git a/queue-4.16/mm-ksm.c-fix-inconsistent-accounting-of-zero-pages.patch b/queue-4.16/mm-ksm.c-fix-inconsistent-accounting-of-zero-pages.patch new file mode 100644 index 00000000000..ebce3d9861d --- /dev/null +++ b/queue-4.16/mm-ksm.c-fix-inconsistent-accounting-of-zero-pages.patch @@ -0,0 +1,50 @@ +From a38c015f3156895b07e71d4e4414289f8a3b2745 Mon Sep 17 00:00:00 2001 +From: Claudio Imbrenda +Date: Tue, 10 Apr 2018 16:29:41 -0700 +Subject: mm/ksm.c: fix inconsistent accounting of zero pages + +From: Claudio Imbrenda + +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 +Reviewed-by: Andrew Morton +Cc: Andrea Arcangeli +Cc: Minchan Kim +Cc: Kirill A. Shutemov +Cc: Hugh Dickins +Cc: Christian Borntraeger +Cc: Gerald Schaefer +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + 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)); diff --git a/queue-4.16/mm-slab-reschedule-cache_reap-on-the-same-cpu.patch b/queue-4.16/mm-slab-reschedule-cache_reap-on-the-same-cpu.patch new file mode 100644 index 00000000000..e54b72bc202 --- /dev/null +++ b/queue-4.16/mm-slab-reschedule-cache_reap-on-the-same-cpu.patch @@ -0,0 +1,57 @@ +From a9f2a846f0503e7d729f552e3ccfe2279010fe94 Mon Sep 17 00:00:00 2001 +From: Vlastimil Babka +Date: Fri, 13 Apr 2018 15:35:38 -0700 +Subject: mm, slab: reschedule cache_reap() on the same CPU + +From: Vlastimil Babka + +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 +Acked-by: Pekka Enberg +Acked-by: Christoph Lameter +Cc: Joonsoo Kim +Cc: David Rientjes +Cc: Tejun Heo +Cc: Lai Jiangshan +Cc: John Stultz +Cc: Thomas Gleixner +Cc: Stephen Boyd +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + 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) diff --git a/queue-4.16/phy-allwinner-sun4i-usb-poll-vbus-changes-on-a23-a33-when-driving-vbus.patch b/queue-4.16/phy-allwinner-sun4i-usb-poll-vbus-changes-on-a23-a33-when-driving-vbus.patch new file mode 100644 index 00000000000..2c32b437ae5 --- /dev/null +++ b/queue-4.16/phy-allwinner-sun4i-usb-poll-vbus-changes-on-a23-a33-when-driving-vbus.patch @@ -0,0 +1,78 @@ +From d7119224bfe6e8efbf821a52db7da9530d790f07 Mon Sep 17 00:00:00 2001 +From: Chen-Yu Tsai +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 + +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: # 4.3.x: 68dbc2ce77bb phy-sun4i-usb: + Use of_match_node to get model specific config data +Cc: # 4.3.x: 5cf700ac9d50 phy: phy-sun4i-usb: + Fix optional gpios failing probe +Cc: # 4.3.x: 04e59a0211ff phy-sun4i-usb: + Fix irq free conditions to match request conditions +Cc: # 4.3.x: 91d96f06a760 phy-sun4i-usb: + Add workaround for missing Vbus det interrupts on A31 +Cc: # 4.3.x +Signed-off-by: Chen-Yu Tsai +Acked-by: Maxime Ripard +Signed-off-by: Kishon Vijay Abraham I +Signed-off-by: Greg Kroah-Hartman + +Signed-off-by: Kishon Vijay Abraham I + +--- + 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, diff --git a/queue-4.16/resource-fix-integer-overflow-at-reallocation.patch b/queue-4.16/resource-fix-integer-overflow-at-reallocation.patch new file mode 100644 index 00000000000..550988afeea --- /dev/null +++ b/queue-4.16/resource-fix-integer-overflow-at-reallocation.patch @@ -0,0 +1,55 @@ +From 60bb83b81169820c691fbfa33a6a4aef32aa4b0b Mon Sep 17 00:00:00 2001 +From: Takashi Iwai +Date: Fri, 13 Apr 2018 15:35:13 -0700 +Subject: resource: fix integer overflow at reallocation + +From: Takashi Iwai + +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 +Reported-by: Michael Henders +Tested-by: Michael Henders +Reviewed-by: Andrew Morton +Cc: Ram Pai +Cc: Bjorn Helgaas +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + 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; diff --git a/queue-4.16/series b/queue-4.16/series index e69de29bb2d..fe798f2187c 100644 --- a/queue-4.16/series +++ b/queue-4.16/series @@ -0,0 +1,19 @@ +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 diff --git a/queue-4.16/task_struct-only-use-anon-struct-under-randstruct-plugin.patch b/queue-4.16/task_struct-only-use-anon-struct-under-randstruct-plugin.patch new file mode 100644 index 00000000000..90bc5843401 --- /dev/null +++ b/queue-4.16/task_struct-only-use-anon-struct-under-randstruct-plugin.patch @@ -0,0 +1,72 @@ +From 2cfe0d3009418a132b93d78642a8059a38fe5944 Mon Sep 17 00:00:00 2001 +From: Kees Cook +Date: Tue, 10 Apr 2018 16:32:44 -0700 +Subject: task_struct: only use anon struct under randstruct plugin + +From: Kees Cook + +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 +Reported-by: Peter Zijlstra +Cc: Peter Zijlstra +Cc: Ingo Molnar +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + 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 */ + + diff --git a/queue-4.16/ubi-fastmap-don-t-flush-fastmap-work-on-detach.patch b/queue-4.16/ubi-fastmap-don-t-flush-fastmap-work-on-detach.patch new file mode 100644 index 00000000000..c6277046789 --- /dev/null +++ b/queue-4.16/ubi-fastmap-don-t-flush-fastmap-work-on-detach.patch @@ -0,0 +1,32 @@ +From 29b7a6fa1ec07e8480b0d9caf635a4498a438bf4 Mon Sep 17 00:00:00 2001 +From: Richard Weinberger +Date: Wed, 17 Jan 2018 23:15:57 +0100 +Subject: ubi: fastmap: Don't flush fastmap work on detach + +From: Richard Weinberger + +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 +Fixes: 74cdaf24004a ("UBI: Fastmap: Fix memory leaks while closing the WL sub-system") +Cc: stable@vger.kernel.org +Signed-off-by: Richard Weinberger +Signed-off-by: Greg Kroah-Hartman + +--- + 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); + diff --git a/queue-4.16/ubi-fix-error-for-write-access.patch b/queue-4.16/ubi-fix-error-for-write-access.patch new file mode 100644 index 00000000000..8f6c4a1e9c6 --- /dev/null +++ b/queue-4.16/ubi-fix-error-for-write-access.patch @@ -0,0 +1,42 @@ +From 78a8dfbabbece22bee58ac4cb26cab10e7a19c5d Mon Sep 17 00:00:00 2001 +From: Romain Izard +Date: Mon, 29 Jan 2018 11:18:20 +0100 +Subject: ubi: Fix error for write access + +From: Romain Izard + +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 +Signed-off-by: Richard Weinberger +Signed-off-by: Greg Kroah-Hartman + +--- + 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; + } + diff --git a/queue-4.16/ubi-reject-mlc-nand.patch b/queue-4.16/ubi-reject-mlc-nand.patch new file mode 100644 index 00000000000..3fb3771db78 --- /dev/null +++ b/queue-4.16/ubi-reject-mlc-nand.patch @@ -0,0 +1,45 @@ +From b5094b7f135be34630e3ea8a98fa215715d0f29d Mon Sep 17 00:00:00 2001 +From: Richard Weinberger +Date: Sat, 3 Mar 2018 11:45:54 +0100 +Subject: ubi: Reject MLC NAND + +From: Richard Weinberger + +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 +Acked-by: Boris Brezillon +Acked-by: Artem Bityutskiy +Signed-off-by: Greg Kroah-Hartman + +--- + 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++) diff --git a/queue-4.16/ubifs-check-ubifs_wbuf_sync-return-code.patch b/queue-4.16/ubifs-check-ubifs_wbuf_sync-return-code.patch new file mode 100644 index 00000000000..a33b40df83f --- /dev/null +++ b/queue-4.16/ubifs-check-ubifs_wbuf_sync-return-code.patch @@ -0,0 +1,54 @@ +From aac17948a7ce01fb60b9ee6cf902967a47b3ce26 Mon Sep 17 00:00:00 2001 +From: Richard Weinberger +Date: Wed, 17 Jan 2018 19:12:42 +0100 +Subject: ubifs: Check ubifs_wbuf_sync() return code + +From: Richard Weinberger + +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: +Fixes: 1e51764a3c2a ("UBIFS: add new flash file system") +Signed-off-by: Richard Weinberger +Signed-off-by: Greg Kroah-Hartman + +--- + 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 diff --git a/queue-4.16/usb-gadget-udc-core-update-usb_ep_queue-documentation.patch b/queue-4.16/usb-gadget-udc-core-update-usb_ep_queue-documentation.patch new file mode 100644 index 00000000000..687f10b0d86 --- /dev/null +++ b/queue-4.16/usb-gadget-udc-core-update-usb_ep_queue-documentation.patch @@ -0,0 +1,32 @@ +From eaa358c7790338d83bb6a31258bdc077de120414 Mon Sep 17 00:00:00 2001 +From: Felipe Balbi +Date: Mon, 26 Mar 2018 13:14:46 +0300 +Subject: usb: gadget: udc: core: update usb_ep_queue() documentation + +From: Felipe Balbi + +commit eaa358c7790338d83bb6a31258bdc077de120414 upstream. + +Mention that ->complete() should never be called from within +usb_ep_queue(). + +Signed-off-by: Felipe Balbi +Cc: stable +Signed-off-by: Greg Kroah-Hartman + +--- + 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. diff --git a/queue-4.16/usb-musb-gadget-misplaced-out-of-bounds-check.patch b/queue-4.16/usb-musb-gadget-misplaced-out-of-bounds-check.patch new file mode 100644 index 00000000000..cd4f73ddf05 --- /dev/null +++ b/queue-4.16/usb-musb-gadget-misplaced-out-of-bounds-check.patch @@ -0,0 +1,48 @@ +From af6f8529098aeb0e56a68671b450cf74e7a64fcd Mon Sep 17 00:00:00 2001 +From: Heinrich Schuchardt +Date: Thu, 29 Mar 2018 10:48:28 -0500 +Subject: usb: musb: gadget: misplaced out of bounds check + +From: Heinrich Schuchardt + +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 +Signed-off-by: Bin Liu +Cc: stable +Signed-off-by: Greg Kroah-Hartman + +--- + 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; + }