From: Sasha Levin Date: Thu, 4 Apr 2019 03:43:25 +0000 (-0400) Subject: fixes for 3.18 X-Git-Tag: v4.9.168~5 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=9a904337ad40e1392c1790d84f8cf78fe9226fa4;p=thirdparty%2Fkernel%2Fstable-queue.git fixes for 3.18 Signed-off-by: Sasha Levin --- diff --git a/queue-3.18/alsa-pcm-check-if-ops-are-defined-before-suspending-.patch b/queue-3.18/alsa-pcm-check-if-ops-are-defined-before-suspending-.patch new file mode 100644 index 00000000000..7b60e297c5c --- /dev/null +++ b/queue-3.18/alsa-pcm-check-if-ops-are-defined-before-suspending-.patch @@ -0,0 +1,49 @@ +From 5656b979bd41a1f2e301d4bdf98b2731014145c9 Mon Sep 17 00:00:00 2001 +From: Ranjani Sridharan +Date: Fri, 8 Feb 2019 17:29:53 -0600 +Subject: ALSA: PCM: check if ops are defined before suspending PCM + +[ Upstream commit d9c0b2afe820fa3b3f8258a659daee2cc71ca3ef ] + +BE dai links only have internal PCM's and their substream ops may +not be set. Suspending these PCM's will result in their + ops->trigger() being invoked and cause a kernel oops. +So skip suspending PCM's if their ops are NULL. + +[ NOTE: this change is required now for following the recent PCM core + change to get rid of snd_pcm_suspend() call. Since DPCM BE takes + the runtime carried from FE while keeping NULL ops, it can hit this + bug. See details at: + https://github.com/thesofproject/linux/pull/582 + -- tiwai ] + +Signed-off-by: Ranjani Sridharan +Signed-off-by: Pierre-Louis Bossart +Signed-off-by: Takashi Iwai +Signed-off-by: Sasha Levin +--- + sound/core/pcm_native.c | 8 ++++++++ + 1 file changed, 8 insertions(+) + +diff --git a/sound/core/pcm_native.c b/sound/core/pcm_native.c +index a79edb3e8284..29a088e03657 100644 +--- a/sound/core/pcm_native.c ++++ b/sound/core/pcm_native.c +@@ -1315,6 +1315,14 @@ int snd_pcm_suspend_all(struct snd_pcm *pcm) + /* FIXME: the open/close code should lock this as well */ + if (substream->runtime == NULL) + continue; ++ ++ /* ++ * Skip BE dai link PCM's that are internal and may ++ * not have their substream ops set. ++ */ ++ if (!substream->ops) ++ continue; ++ + err = snd_pcm_suspend(substream); + if (err < 0 && err != -EBUSY) + return err; +-- +2.19.1 + diff --git a/queue-3.18/arm-8833-1-ensure-that-neon-code-always-compiles-wit.patch b/queue-3.18/arm-8833-1-ensure-that-neon-code-always-compiles-wit.patch new file mode 100644 index 00000000000..8b2e0acf93e --- /dev/null +++ b/queue-3.18/arm-8833-1-ensure-that-neon-code-always-compiles-wit.patch @@ -0,0 +1,122 @@ +From ffb91ff7e5711dfd82ea69cba1744a9041acae2b Mon Sep 17 00:00:00 2001 +From: Nathan Chancellor +Date: Sat, 2 Feb 2019 03:34:36 +0100 +Subject: ARM: 8833/1: Ensure that NEON code always compiles with Clang + +[ Upstream commit de9c0d49d85dc563549972edc5589d195cd5e859 ] + +While building arm32 allyesconfig, I ran into the following errors: + + arch/arm/lib/xor-neon.c:17:2: error: You should compile this file with + '-mfloat-abi=softfp -mfpu=neon' + + In file included from lib/raid6/neon1.c:27: + /home/nathan/cbl/prebuilt/lib/clang/8.0.0/include/arm_neon.h:28:2: + error: "NEON support not enabled" + +Building V=1 showed NEON_FLAGS getting passed along to Clang but +__ARM_NEON__ was not getting defined. Ultimately, it boils down to Clang +only defining __ARM_NEON__ when targeting armv7, rather than armv6k, +which is the '-march' value for allyesconfig. + +>From lib/Basic/Targets/ARM.cpp in the Clang source: + + // This only gets set when Neon instructions are actually available, unlike + // the VFP define, hence the soft float and arch check. This is subtly + // different from gcc, we follow the intent which was that it should be set + // when Neon instructions are actually available. + if ((FPU & NeonFPU) && !SoftFloat && ArchVersion >= 7) { + Builder.defineMacro("__ARM_NEON", "1"); + Builder.defineMacro("__ARM_NEON__"); + // current AArch32 NEON implementations do not support double-precision + // floating-point even when it is present in VFP. + Builder.defineMacro("__ARM_NEON_FP", + "0x" + Twine::utohexstr(HW_FP & ~HW_FP_DP)); + } + +Ard Biesheuvel recommended explicitly adding '-march=armv7-a' at the +beginning of the NEON_FLAGS definitions so that __ARM_NEON__ always gets +definined by Clang. This doesn't functionally change anything because +that code will only run where NEON is supported, which is implicitly +armv7. + +Link: https://github.com/ClangBuiltLinux/linux/issues/287 + +Suggested-by: Ard Biesheuvel +Signed-off-by: Nathan Chancellor +Acked-by: Nicolas Pitre +Reviewed-by: Nick Desaulniers +Reviewed-by: Stefan Agner +Signed-off-by: Russell King +Signed-off-by: Sasha Levin +--- + Documentation/arm/kernel_mode_neon.txt | 4 ++-- + arch/arm/lib/Makefile | 2 +- + arch/arm/lib/xor-neon.c | 2 +- + lib/raid6/Makefile | 2 +- + 4 files changed, 5 insertions(+), 5 deletions(-) + +diff --git a/Documentation/arm/kernel_mode_neon.txt b/Documentation/arm/kernel_mode_neon.txt +index 525452726d31..b9e060c5b61e 100644 +--- a/Documentation/arm/kernel_mode_neon.txt ++++ b/Documentation/arm/kernel_mode_neon.txt +@@ -6,7 +6,7 @@ TL;DR summary + * Use only NEON instructions, or VFP instructions that don't rely on support + code + * Isolate your NEON code in a separate compilation unit, and compile it with +- '-mfpu=neon -mfloat-abi=softfp' ++ '-march=armv7-a -mfpu=neon -mfloat-abi=softfp' + * Put kernel_neon_begin() and kernel_neon_end() calls around the calls into your + NEON code + * Don't sleep in your NEON code, and be aware that it will be executed with +@@ -87,7 +87,7 @@ instructions appearing in unexpected places if no special care is taken. + Therefore, the recommended and only supported way of using NEON/VFP in the + kernel is by adhering to the following rules: + * isolate the NEON code in a separate compilation unit and compile it with +- '-mfpu=neon -mfloat-abi=softfp'; ++ '-march=armv7-a -mfpu=neon -mfloat-abi=softfp'; + * issue the calls to kernel_neon_begin(), kernel_neon_end() as well as the calls + into the unit containing the NEON code from a compilation unit which is *not* + built with the GCC flag '-mfpu=neon' set. +diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile +index 0573faab96ad..830b2ddcc346 100644 +--- a/arch/arm/lib/Makefile ++++ b/arch/arm/lib/Makefile +@@ -46,7 +46,7 @@ $(obj)/csumpartialcopy.o: $(obj)/csumpartialcopygeneric.S + $(obj)/csumpartialcopyuser.o: $(obj)/csumpartialcopygeneric.S + + ifeq ($(CONFIG_KERNEL_MODE_NEON),y) +- NEON_FLAGS := -mfloat-abi=softfp -mfpu=neon ++ NEON_FLAGS := -march=armv7-a -mfloat-abi=softfp -mfpu=neon + CFLAGS_xor-neon.o += $(NEON_FLAGS) + obj-$(CONFIG_XOR_BLOCKS) += xor-neon.o + endif +diff --git a/arch/arm/lib/xor-neon.c b/arch/arm/lib/xor-neon.c +index 2c40aeab3eaa..c691b901092f 100644 +--- a/arch/arm/lib/xor-neon.c ++++ b/arch/arm/lib/xor-neon.c +@@ -14,7 +14,7 @@ + MODULE_LICENSE("GPL"); + + #ifndef __ARM_NEON__ +-#error You should compile this file with '-mfloat-abi=softfp -mfpu=neon' ++#error You should compile this file with '-march=armv7-a -mfloat-abi=softfp -mfpu=neon' + #endif + + /* +diff --git a/lib/raid6/Makefile b/lib/raid6/Makefile +index c7dab0645554..1c3330dc5eab 100644 +--- a/lib/raid6/Makefile ++++ b/lib/raid6/Makefile +@@ -23,7 +23,7 @@ endif + ifeq ($(CONFIG_KERNEL_MODE_NEON),y) + NEON_FLAGS := -ffreestanding + ifeq ($(ARCH),arm) +-NEON_FLAGS += -mfloat-abi=softfp -mfpu=neon ++NEON_FLAGS += -march=armv7-a -mfloat-abi=softfp -mfpu=neon + endif + ifeq ($(ARCH),arm64) + CFLAGS_REMOVE_neon1.o += -mgeneral-regs-only +-- +2.19.1 + diff --git a/queue-3.18/arm-8840-1-use-a-raw_spinlock_t-in-unwind.patch b/queue-3.18/arm-8840-1-use-a-raw_spinlock_t-in-unwind.patch new file mode 100644 index 00000000000..137dbc41354 --- /dev/null +++ b/queue-3.18/arm-8840-1-use-a-raw_spinlock_t-in-unwind.patch @@ -0,0 +1,92 @@ +From 5d45ee5fb7fd75c83fb5964140686465334c50d3 Mon Sep 17 00:00:00 2001 +From: Sebastian Andrzej Siewior +Date: Wed, 13 Feb 2019 17:14:42 +0100 +Subject: ARM: 8840/1: use a raw_spinlock_t in unwind + +[ Upstream commit 74ffe79ae538283bbf7c155e62339f1e5c87b55a ] + +Mostly unwind is done with irqs enabled however SLUB may call it with +irqs disabled while creating a new SLUB cache. + +I had system freeze while loading a module which called +kmem_cache_create() on init. That means SLUB's __slab_alloc() disabled +interrupts and then + +->new_slab_objects() + ->new_slab() + ->setup_object() + ->setup_object_debug() + ->init_tracking() + ->set_track() + ->save_stack_trace() + ->save_stack_trace_tsk() + ->walk_stackframe() + ->unwind_frame() + ->unwind_find_idx() + =>spin_lock_irqsave(&unwind_lock); + +Signed-off-by: Sebastian Andrzej Siewior +Signed-off-by: Russell King +Signed-off-by: Sasha Levin +--- + arch/arm/kernel/unwind.c | 14 +++++++------- + 1 file changed, 7 insertions(+), 7 deletions(-) + +diff --git a/arch/arm/kernel/unwind.c b/arch/arm/kernel/unwind.c +index cbb85c5fabf9..5184fe85d167 100644 +--- a/arch/arm/kernel/unwind.c ++++ b/arch/arm/kernel/unwind.c +@@ -93,7 +93,7 @@ extern const struct unwind_idx __start_unwind_idx[]; + static const struct unwind_idx *__origin_unwind_idx; + extern const struct unwind_idx __stop_unwind_idx[]; + +-static DEFINE_SPINLOCK(unwind_lock); ++static DEFINE_RAW_SPINLOCK(unwind_lock); + static LIST_HEAD(unwind_tables); + + /* Convert a prel31 symbol to an absolute address */ +@@ -201,7 +201,7 @@ static const struct unwind_idx *unwind_find_idx(unsigned long addr) + /* module unwind tables */ + struct unwind_table *table; + +- spin_lock_irqsave(&unwind_lock, flags); ++ raw_spin_lock_irqsave(&unwind_lock, flags); + list_for_each_entry(table, &unwind_tables, list) { + if (addr >= table->begin_addr && + addr < table->end_addr) { +@@ -213,7 +213,7 @@ static const struct unwind_idx *unwind_find_idx(unsigned long addr) + break; + } + } +- spin_unlock_irqrestore(&unwind_lock, flags); ++ raw_spin_unlock_irqrestore(&unwind_lock, flags); + } + + pr_debug("%s: idx = %p\n", __func__, idx); +@@ -530,9 +530,9 @@ struct unwind_table *unwind_table_add(unsigned long start, unsigned long size, + tab->begin_addr = text_addr; + tab->end_addr = text_addr + text_size; + +- spin_lock_irqsave(&unwind_lock, flags); ++ raw_spin_lock_irqsave(&unwind_lock, flags); + list_add_tail(&tab->list, &unwind_tables); +- spin_unlock_irqrestore(&unwind_lock, flags); ++ raw_spin_unlock_irqrestore(&unwind_lock, flags); + + return tab; + } +@@ -544,9 +544,9 @@ void unwind_table_del(struct unwind_table *tab) + if (!tab) + return; + +- spin_lock_irqsave(&unwind_lock, flags); ++ raw_spin_lock_irqsave(&unwind_lock, flags); + list_del(&tab->list); +- spin_unlock_irqrestore(&unwind_lock, flags); ++ raw_spin_unlock_irqrestore(&unwind_lock, flags); + + kfree(tab); + } +-- +2.19.1 + diff --git a/queue-3.18/bcache-fix-input-overflow-to-cache-set-sysfs-file-io.patch b/queue-3.18/bcache-fix-input-overflow-to-cache-set-sysfs-file-io.patch new file mode 100644 index 00000000000..b6a8acd2b3e --- /dev/null +++ b/queue-3.18/bcache-fix-input-overflow-to-cache-set-sysfs-file-io.patch @@ -0,0 +1,50 @@ +From 1b16bdaaa871229f8715e4ebb07b01d489cd3432 Mon Sep 17 00:00:00 2001 +From: Coly Li +Date: Sat, 9 Feb 2019 12:53:10 +0800 +Subject: bcache: fix input overflow to cache set sysfs file io_error_halflife + +[ Upstream commit a91fbda49f746119828f7e8ad0f0aa2ab0578f65 ] + +Cache set sysfs entry io_error_halflife is used to set c->error_decay. +c->error_decay is in type unsigned int, and it is converted by +strtoul_or_return(), therefore overflow to c->error_decay is possible +for a large input value. + +This patch fixes the overflow by using strtoul_safe_clamp() to convert +input string to an unsigned long value in range [0, UINT_MAX], then +divides by 88 and set it to c->error_decay. + +Signed-off-by: Coly Li +Signed-off-by: Jens Axboe +Signed-off-by: Sasha Levin +--- + drivers/md/bcache/sysfs.c | 13 +++++++++++-- + 1 file changed, 11 insertions(+), 2 deletions(-) + +diff --git a/drivers/md/bcache/sysfs.c b/drivers/md/bcache/sysfs.c +index 5a5c1f1bd8a5..87daccbbc61b 100644 +--- a/drivers/md/bcache/sysfs.c ++++ b/drivers/md/bcache/sysfs.c +@@ -645,8 +645,17 @@ STORE(__bch_cache_set) + c->error_limit = strtoul_or_return(buf) << IO_ERROR_SHIFT; + + /* See count_io_errors() for why 88 */ +- if (attr == &sysfs_io_error_halflife) +- c->error_decay = strtoul_or_return(buf) / 88; ++ if (attr == &sysfs_io_error_halflife) { ++ unsigned long v = 0; ++ ssize_t ret; ++ ++ ret = strtoul_safe_clamp(buf, v, 0, UINT_MAX); ++ if (!ret) { ++ c->error_decay = v / 88; ++ return size; ++ } ++ return ret; ++ } + + sysfs_strtoul(journal_delay_ms, c->journal_delay_ms); + sysfs_strtoul(verify, c->verify); +-- +2.19.1 + diff --git a/queue-3.18/bcache-fix-input-overflow-to-sequential_cutoff.patch b/queue-3.18/bcache-fix-input-overflow-to-sequential_cutoff.patch new file mode 100644 index 00000000000..fa075d0af81 --- /dev/null +++ b/queue-3.18/bcache-fix-input-overflow-to-sequential_cutoff.patch @@ -0,0 +1,42 @@ +From c37d5910f6f079e734ea108d9a2835b63f0a0f02 Mon Sep 17 00:00:00 2001 +From: Coly Li +Date: Sat, 9 Feb 2019 12:53:01 +0800 +Subject: bcache: fix input overflow to sequential_cutoff + +[ Upstream commit 8c27a3953e92eb0b22dbb03d599f543a05f9574e ] + +People may set sequential_cutoff of a cached device via sysfs file, +but current code does not check input value overflow. E.g. if value +4294967295 (UINT_MAX) is written to file sequential_cutoff, its value +is 4GB, but if 4294967296 (UINT_MAX + 1) is written into, its value +will be 0. This is an unexpected behavior. + +This patch replaces d_strtoi_h() by sysfs_strtoul_clamp() to convert +input string to unsigned integer value, and limit its range in +[0, UINT_MAX]. Then the input overflow can be fixed. + +Signed-off-by: Coly Li +Signed-off-by: Jens Axboe +Signed-off-by: Sasha Levin +--- + drivers/md/bcache/sysfs.c | 4 +++- + 1 file changed, 3 insertions(+), 1 deletion(-) + +diff --git a/drivers/md/bcache/sysfs.c b/drivers/md/bcache/sysfs.c +index 87daccbbc61b..463ce6757338 100644 +--- a/drivers/md/bcache/sysfs.c ++++ b/drivers/md/bcache/sysfs.c +@@ -215,7 +215,9 @@ STORE(__cached_dev) + d_strtoul(writeback_rate_d_term); + d_strtoul_nonzero(writeback_rate_p_term_inverse); + +- d_strtoi_h(sequential_cutoff); ++ sysfs_strtoul_clamp(sequential_cutoff, ++ dc->sequential_cutoff, ++ 0, UINT_MAX); + d_strtoi_h(readahead); + + if (attr == &sysfs_clear_stats) +-- +2.19.1 + diff --git a/queue-3.18/bcache-improve-sysfs_strtoul_clamp.patch b/queue-3.18/bcache-improve-sysfs_strtoul_clamp.patch new file mode 100644 index 00000000000..64cb9eb4436 --- /dev/null +++ b/queue-3.18/bcache-improve-sysfs_strtoul_clamp.patch @@ -0,0 +1,64 @@ +From 000433ed7f83bccfdf998357396a7afc81d3d203 Mon Sep 17 00:00:00 2001 +From: Coly Li +Date: Sat, 9 Feb 2019 12:52:59 +0800 +Subject: bcache: improve sysfs_strtoul_clamp() + +[ Upstream commit 596b5a5dd1bc2fa019fdaaae522ef331deef927f ] + +Currently sysfs_strtoul_clamp() is defined as, + 82 #define sysfs_strtoul_clamp(file, var, min, max) \ + 83 do { \ + 84 if (attr == &sysfs_ ## file) \ + 85 return strtoul_safe_clamp(buf, var, min, max) \ + 86 ?: (ssize_t) size; \ + 87 } while (0) + +The problem is, if bit width of var is less then unsigned long, min and +max may not protect var from integer overflow, because overflow happens +in strtoul_safe_clamp() before checking min and max. + +To fix such overflow in sysfs_strtoul_clamp(), to make min and max take +effect, this patch adds an unsigned long variable, and uses it to macro +strtoul_safe_clamp() to convert an unsigned long value in range defined +by [min, max]. Then assign this value to var. By this method, if bit +width of var is less than unsigned long, integer overflow won't happen +before min and max are checking. + +Now sysfs_strtoul_clamp() can properly handle smaller data type like +unsigned int, of cause min and max should be defined in range of +unsigned int too. + +Signed-off-by: Coly Li +Signed-off-by: Jens Axboe +Signed-off-by: Sasha Levin +--- + drivers/md/bcache/sysfs.h | 13 ++++++++++--- + 1 file changed, 10 insertions(+), 3 deletions(-) + +diff --git a/drivers/md/bcache/sysfs.h b/drivers/md/bcache/sysfs.h +index 0526fe92a683..e7a3c12aa66f 100644 +--- a/drivers/md/bcache/sysfs.h ++++ b/drivers/md/bcache/sysfs.h +@@ -80,9 +80,16 @@ do { \ + + #define sysfs_strtoul_clamp(file, var, min, max) \ + do { \ +- if (attr == &sysfs_ ## file) \ +- return strtoul_safe_clamp(buf, var, min, max) \ +- ?: (ssize_t) size; \ ++ if (attr == &sysfs_ ## file) { \ ++ unsigned long v = 0; \ ++ ssize_t ret; \ ++ ret = strtoul_safe_clamp(buf, v, min, max); \ ++ if (!ret) { \ ++ var = v; \ ++ return size; \ ++ } \ ++ return ret; \ ++ } \ + } while (0) + + #define strtoul_or_return(cp) \ +-- +2.19.1 + diff --git a/queue-3.18/cdrom-fix-race-condition-in-cdrom_sysctl_register.patch b/queue-3.18/cdrom-fix-race-condition-in-cdrom_sysctl_register.patch new file mode 100644 index 00000000000..c7a2b38e886 --- /dev/null +++ b/queue-3.18/cdrom-fix-race-condition-in-cdrom_sysctl_register.patch @@ -0,0 +1,99 @@ +From 2550d9b205f88cb6a8053c5405c98a15d221dfc4 Mon Sep 17 00:00:00 2001 +From: Guenter Roeck +Date: Wed, 6 Feb 2019 21:13:49 -0800 +Subject: cdrom: Fix race condition in cdrom_sysctl_register + +[ Upstream commit f25191bb322dec8fa2979ecb8235643aa42470e1 ] + +The following traceback is sometimes seen when booting an image in qemu: + +[ 54.608293] cdrom: Uniform CD-ROM driver Revision: 3.20 +[ 54.611085] Fusion MPT base driver 3.04.20 +[ 54.611877] Copyright (c) 1999-2008 LSI Corporation +[ 54.616234] Fusion MPT SAS Host driver 3.04.20 +[ 54.635139] sysctl duplicate entry: /dev/cdrom//info +[ 54.639578] CPU: 0 PID: 266 Comm: kworker/u4:5 Not tainted 5.0.0-rc5 #1 +[ 54.639578] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 +[ 54.641273] Workqueue: events_unbound async_run_entry_fn +[ 54.641273] Call Trace: +[ 54.641273] dump_stack+0x67/0x90 +[ 54.641273] __register_sysctl_table+0x50b/0x570 +[ 54.641273] ? rcu_read_lock_sched_held+0x6f/0x80 +[ 54.641273] ? kmem_cache_alloc_trace+0x1c7/0x1f0 +[ 54.646814] __register_sysctl_paths+0x1c8/0x1f0 +[ 54.646814] cdrom_sysctl_register.part.7+0xc/0x5f +[ 54.646814] register_cdrom.cold.24+0x2a/0x33 +[ 54.646814] sr_probe+0x4bd/0x580 +[ 54.646814] ? __driver_attach+0xd0/0xd0 +[ 54.646814] really_probe+0xd6/0x260 +[ 54.646814] ? __driver_attach+0xd0/0xd0 +[ 54.646814] driver_probe_device+0x4a/0xb0 +[ 54.646814] ? __driver_attach+0xd0/0xd0 +[ 54.646814] bus_for_each_drv+0x73/0xc0 +[ 54.646814] __device_attach+0xd6/0x130 +[ 54.646814] bus_probe_device+0x9a/0xb0 +[ 54.646814] device_add+0x40c/0x670 +[ 54.646814] ? __pm_runtime_resume+0x4f/0x80 +[ 54.646814] scsi_sysfs_add_sdev+0x81/0x290 +[ 54.646814] scsi_probe_and_add_lun+0x888/0xc00 +[ 54.646814] ? scsi_autopm_get_host+0x21/0x40 +[ 54.646814] __scsi_add_device+0x116/0x130 +[ 54.646814] ata_scsi_scan_host+0x93/0x1c0 +[ 54.646814] async_run_entry_fn+0x34/0x100 +[ 54.646814] process_one_work+0x237/0x5e0 +[ 54.646814] worker_thread+0x37/0x380 +[ 54.646814] ? rescuer_thread+0x360/0x360 +[ 54.646814] kthread+0x118/0x130 +[ 54.646814] ? kthread_create_on_node+0x60/0x60 +[ 54.646814] ret_from_fork+0x3a/0x50 + +The only sensible explanation is that cdrom_sysctl_register() is called +twice, once from the module init function and once from register_cdrom(). +cdrom_sysctl_register() is not mutex protected and may happily execute +twice if the second call is made before the first call is complete. + +Use a static atomic to ensure that the function is executed exactly once. + +Signed-off-by: Guenter Roeck +Signed-off-by: Jens Axboe +Signed-off-by: Sasha Levin +--- + drivers/cdrom/cdrom.c | 7 +++---- + 1 file changed, 3 insertions(+), 4 deletions(-) + +diff --git a/drivers/cdrom/cdrom.c b/drivers/cdrom/cdrom.c +index 2bd91d4943e1..f4f93ca4bdad 100644 +--- a/drivers/cdrom/cdrom.c ++++ b/drivers/cdrom/cdrom.c +@@ -265,6 +265,7 @@ + /* #define ERRLOGMASK (CD_WARNING|CD_OPEN|CD_COUNT_TRACKS|CD_CLOSE) */ + /* #define ERRLOGMASK (CD_WARNING|CD_REG_UNREG|CD_DO_IOCTL|CD_OPEN|CD_CLOSE|CD_COUNT_TRACKS) */ + ++#include + #include + #include + #include +@@ -3676,9 +3677,9 @@ static struct ctl_table_header *cdrom_sysctl_header; + + static void cdrom_sysctl_register(void) + { +- static int initialized; ++ static atomic_t initialized = ATOMIC_INIT(0); + +- if (initialized == 1) ++ if (!atomic_add_unless(&initialized, 1, 1)) + return; + + cdrom_sysctl_header = register_sysctl_table(cdrom_root_table); +@@ -3689,8 +3690,6 @@ static void cdrom_sysctl_register(void) + cdrom_sysctl_settings.debug = debug; + cdrom_sysctl_settings.lock = lockdoor; + cdrom_sysctl_settings.check = check_media_type; +- +- initialized = 1; + } + + static void cdrom_sysctl_unregister(void) +-- +2.19.1 + diff --git a/queue-3.18/cifs-fix-null-pointer-dereference-of-devname.patch b/queue-3.18/cifs-fix-null-pointer-dereference-of-devname.patch new file mode 100644 index 00000000000..5c891c499f8 --- /dev/null +++ b/queue-3.18/cifs-fix-null-pointer-dereference-of-devname.patch @@ -0,0 +1,60 @@ +From f05aa16002570799541cdfa4be0dab4b91e7a48f Mon Sep 17 00:00:00 2001 +From: Yao Liu +Date: Mon, 28 Jan 2019 19:47:28 +0800 +Subject: cifs: Fix NULL pointer dereference of devname + +[ Upstream commit 68e2672f8fbd1e04982b8d2798dd318bf2515dd2 ] + +There is a NULL pointer dereference of devname in strspn() + +The oops looks something like: + + CIFS: Attempting to mount (null) + BUG: unable to handle kernel NULL pointer dereference at 0000000000000000 + ... + RIP: 0010:strspn+0x0/0x50 + ... + Call Trace: + ? cifs_parse_mount_options+0x222/0x1710 [cifs] + ? cifs_get_volume_info+0x2f/0x80 [cifs] + cifs_setup_volume_info+0x20/0x190 [cifs] + cifs_get_volume_info+0x50/0x80 [cifs] + cifs_smb3_do_mount+0x59/0x630 [cifs] + ? ida_alloc_range+0x34b/0x3d0 + cifs_do_mount+0x11/0x20 [cifs] + mount_fs+0x52/0x170 + vfs_kern_mount+0x6b/0x170 + do_mount+0x216/0xdc0 + ksys_mount+0x83/0xd0 + __x64_sys_mount+0x25/0x30 + do_syscall_64+0x65/0x220 + entry_SYSCALL_64_after_hwframe+0x49/0xbe + +Fix this by adding a NULL check on devname in cifs_parse_devname() + +Signed-off-by: Yao Liu +Signed-off-by: Steve French +Signed-off-by: Sasha Levin +--- + fs/cifs/connect.c | 5 +++++ + 1 file changed, 5 insertions(+) + +diff --git a/fs/cifs/connect.c b/fs/cifs/connect.c +index 7d4c2bf2fea2..f5f5aab3457f 100644 +--- a/fs/cifs/connect.c ++++ b/fs/cifs/connect.c +@@ -1186,6 +1186,11 @@ cifs_parse_devname(const char *devname, struct smb_vol *vol) + const char *delims = "/\\"; + size_t len; + ++ if (unlikely(!devname || !*devname)) { ++ cifs_dbg(VFS, "Device name not specified.\n"); ++ return -EINVAL; ++ } ++ + /* make sure we have a valid UNC double delimiter prefix */ + len = strspn(devname, delims); + if (len != 2) +-- +2.19.1 + diff --git a/queue-3.18/cifs-use-correct-format-characters.patch b/queue-3.18/cifs-use-correct-format-characters.patch new file mode 100644 index 00000000000..1e4d3bff54b --- /dev/null +++ b/queue-3.18/cifs-use-correct-format-characters.patch @@ -0,0 +1,80 @@ +From bef812c8083e5c7932a1d8ac031bac437341105e Mon Sep 17 00:00:00 2001 +From: Louis Taylor +Date: Wed, 27 Feb 2019 22:25:15 +0000 +Subject: cifs: use correct format characters + +[ Upstream commit 259594bea574e515a148171b5cd84ce5cbdc028a ] + +When compiling with -Wformat, clang emits the following warnings: + +fs/cifs/smb1ops.c:312:20: warning: format specifies type 'unsigned +short' but the argument has type 'unsigned int' [-Wformat] + tgt_total_cnt, total_in_tgt); + ^~~~~~~~~~~~ + +fs/cifs/cifs_dfs_ref.c:289:4: warning: format specifies type 'short' +but the argument has type 'int' [-Wformat] + ref->flags, ref->server_type); + ^~~~~~~~~~ + +fs/cifs/cifs_dfs_ref.c:289:16: warning: format specifies type 'short' +but the argument has type 'int' [-Wformat] + ref->flags, ref->server_type); + ^~~~~~~~~~~~~~~~ + +fs/cifs/cifs_dfs_ref.c:291:4: warning: format specifies type 'short' +but the argument has type 'int' [-Wformat] + ref->ref_flag, ref->path_consumed); + ^~~~~~~~~~~~~ + +fs/cifs/cifs_dfs_ref.c:291:19: warning: format specifies type 'short' +but the argument has type 'int' [-Wformat] + ref->ref_flag, ref->path_consumed); + ^~~~~~~~~~~~~~~~~~ +The types of these arguments are unconditionally defined, so this patch +updates the format character to the correct ones for ints and unsigned +ints. + +Link: https://github.com/ClangBuiltLinux/linux/issues/378 + +Signed-off-by: Louis Taylor +Signed-off-by: Steve French +Reviewed-by: Nick Desaulniers +Signed-off-by: Sasha Levin +--- + fs/cifs/cifs_dfs_ref.c | 4 ++-- + fs/cifs/smb1ops.c | 2 +- + 2 files changed, 3 insertions(+), 3 deletions(-) + +diff --git a/fs/cifs/cifs_dfs_ref.c b/fs/cifs/cifs_dfs_ref.c +index b8602f199815..71263ea90810 100644 +--- a/fs/cifs/cifs_dfs_ref.c ++++ b/fs/cifs/cifs_dfs_ref.c +@@ -265,9 +265,9 @@ static void dump_referral(const struct dfs_info3_param *ref) + { + cifs_dbg(FYI, "DFS: ref path: %s\n", ref->path_name); + cifs_dbg(FYI, "DFS: node path: %s\n", ref->node_name); +- cifs_dbg(FYI, "DFS: fl: %hd, srv_type: %hd\n", ++ cifs_dbg(FYI, "DFS: fl: %d, srv_type: %d\n", + ref->flags, ref->server_type); +- cifs_dbg(FYI, "DFS: ref_flags: %hd, path_consumed: %hd\n", ++ cifs_dbg(FYI, "DFS: ref_flags: %d, path_consumed: %d\n", + ref->ref_flag, ref->path_consumed); + } + +diff --git a/fs/cifs/smb1ops.c b/fs/cifs/smb1ops.c +index b0f973b2b189..2a43aa6d8e87 100644 +--- a/fs/cifs/smb1ops.c ++++ b/fs/cifs/smb1ops.c +@@ -305,7 +305,7 @@ coalesce_t2(char *second_buf, struct smb_hdr *target_hdr) + remaining = tgt_total_cnt - total_in_tgt; + + if (remaining < 0) { +- cifs_dbg(FYI, "Server sent too much data. tgt_total_cnt=%hu total_in_tgt=%hu\n", ++ cifs_dbg(FYI, "Server sent too much data. tgt_total_cnt=%hu total_in_tgt=%u\n", + tgt_total_cnt, total_in_tgt); + return -EPROTO; + } +-- +2.19.1 + diff --git a/queue-3.18/dm-thin-add-sanity-checks-to-thin-pool-and-external-.patch b/queue-3.18/dm-thin-add-sanity-checks-to-thin-pool-and-external-.patch new file mode 100644 index 00000000000..f2f193ab199 --- /dev/null +++ b/queue-3.18/dm-thin-add-sanity-checks-to-thin-pool-and-external-.patch @@ -0,0 +1,111 @@ +From 94c12dc99b0543752bf38a07395053ba21596d1e Mon Sep 17 00:00:00 2001 +From: "Jason Cai (Xiang Feng)" +Date: Sun, 20 Jan 2019 22:39:13 +0800 +Subject: dm thin: add sanity checks to thin-pool and external snapshot + creation + +[ Upstream commit 70de2cbda8a5d788284469e755f8b097d339c240 ] + +Invoking dm_get_device() twice on the same device path with different +modes is dangerous. Because in that case, upgrade_mode() will alloc a +new 'dm_dev' and free the old one, which may be referenced by a previous +caller. Dereferencing the dangling pointer will trigger kernel NULL +pointer dereference. + +The following two cases can reproduce this issue. Actually, they are +invalid setups that must be disallowed, e.g.: + +1. Creating a thin-pool with read_only mode, and the same device as +both metadata and data. + +dmsetup create thinp --table \ + "0 41943040 thin-pool /dev/vdb /dev/vdb 128 0 1 read_only" + +BUG: unable to handle kernel NULL pointer dereference at 0000000000000080 +... +Call Trace: + new_read+0xfb/0x110 [dm_bufio] + dm_bm_read_lock+0x43/0x190 [dm_persistent_data] + ? kmem_cache_alloc_trace+0x15c/0x1e0 + __create_persistent_data_objects+0x65/0x3e0 [dm_thin_pool] + dm_pool_metadata_open+0x8c/0xf0 [dm_thin_pool] + pool_ctr.cold.79+0x213/0x913 [dm_thin_pool] + ? realloc_argv+0x50/0x70 [dm_mod] + dm_table_add_target+0x14e/0x330 [dm_mod] + table_load+0x122/0x2e0 [dm_mod] + ? dev_status+0x40/0x40 [dm_mod] + ctl_ioctl+0x1aa/0x3e0 [dm_mod] + dm_ctl_ioctl+0xa/0x10 [dm_mod] + do_vfs_ioctl+0xa2/0x600 + ? handle_mm_fault+0xda/0x200 + ? __do_page_fault+0x26c/0x4f0 + ksys_ioctl+0x60/0x90 + __x64_sys_ioctl+0x16/0x20 + do_syscall_64+0x55/0x150 + entry_SYSCALL_64_after_hwframe+0x44/0xa9 + +2. Creating a external snapshot using the same thin-pool device. + +dmsetup create thinp --table \ + "0 41943040 thin-pool /dev/vdc /dev/vdb 128 0 2 ignore_discard" +dmsetup message /dev/mapper/thinp 0 "create_thin 0" +dmsetup create snap --table \ + "0 204800 thin /dev/mapper/thinp 0 /dev/mapper/thinp" + +BUG: unable to handle kernel NULL pointer dereference at 0000000000000000 +... +Call Trace: +? __alloc_pages_nodemask+0x13c/0x2e0 +retrieve_status+0xa5/0x1f0 [dm_mod] +? dm_get_live_or_inactive_table.isra.7+0x20/0x20 [dm_mod] + table_status+0x61/0xa0 [dm_mod] + ctl_ioctl+0x1aa/0x3e0 [dm_mod] + dm_ctl_ioctl+0xa/0x10 [dm_mod] + do_vfs_ioctl+0xa2/0x600 + ksys_ioctl+0x60/0x90 + ? ksys_write+0x4f/0xb0 + __x64_sys_ioctl+0x16/0x20 + do_syscall_64+0x55/0x150 + entry_SYSCALL_64_after_hwframe+0x44/0xa9 + +Signed-off-by: Jason Cai (Xiang Feng) +Signed-off-by: Mike Snitzer +Signed-off-by: Sasha Levin +--- + drivers/md/dm-thin.c | 13 +++++++++++++ + 1 file changed, 13 insertions(+) + +diff --git a/drivers/md/dm-thin.c b/drivers/md/dm-thin.c +index 936c57b57539..c50f144bdbcf 100644 +--- a/drivers/md/dm-thin.c ++++ b/drivers/md/dm-thin.c +@@ -2560,6 +2560,13 @@ static int pool_ctr(struct dm_target *ti, unsigned argc, char **argv) + as.argc = argc; + as.argv = argv; + ++ /* make sure metadata and data are different devices */ ++ if (!strcmp(argv[0], argv[1])) { ++ ti->error = "Error setting metadata or data device"; ++ r = -EINVAL; ++ goto out_unlock; ++ } ++ + /* + * Set default pool features. + */ +@@ -3386,6 +3393,12 @@ static int thin_ctr(struct dm_target *ti, unsigned argc, char **argv) + tc->sort_bio_list = RB_ROOT; + + if (argc == 3) { ++ if (!strcmp(argv[0], argv[2])) { ++ ti->error = "Error setting origin device"; ++ r = -EINVAL; ++ goto bad_origin_dev; ++ } ++ + r = dm_get_device(ti, argv[2], FMODE_READ, &origin_dev); + if (r) { + ti->error = "Error opening origin device"; +-- +2.19.1 + diff --git a/queue-3.18/dmaengine-imx-dma-fix-warning-comparison-of-distinct.patch b/queue-3.18/dmaengine-imx-dma-fix-warning-comparison-of-distinct.patch new file mode 100644 index 00000000000..dcfb241216e --- /dev/null +++ b/queue-3.18/dmaengine-imx-dma-fix-warning-comparison-of-distinct.patch @@ -0,0 +1,60 @@ +From 47ee6bca3b5520a5bb665d9c78a43447c9109865 Mon Sep 17 00:00:00 2001 +From: Anders Roxell +Date: Thu, 10 Jan 2019 12:15:35 +0100 +Subject: dmaengine: imx-dma: fix warning comparison of distinct pointer types +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +[ Upstream commit 9227ab5643cb8350449502dd9e3168a873ab0e3b ] + +The warning got introduced by commit 930507c18304 ("arm64: add basic +Kconfig symbols for i.MX8"). Since it got enabled for arm64. The warning +haven't been seen before since size_t was 'unsigned int' when built on +arm32. + +../drivers/dma/imx-dma.c: In function ‘imxdma_sg_next’: +../include/linux/kernel.h:846:29: warning: comparison of distinct pointer types lacks a cast + (!!(sizeof((typeof(x) *)1 == (typeof(y) *)1))) + ^~ +../include/linux/kernel.h:860:4: note: in expansion of macro ‘__typecheck’ + (__typecheck(x, y) && __no_side_effects(x, y)) + ^~~~~~~~~~~ +../include/linux/kernel.h:870:24: note: in expansion of macro ‘__safe_cmp’ + __builtin_choose_expr(__safe_cmp(x, y), \ + ^~~~~~~~~~ +../include/linux/kernel.h:879:19: note: in expansion of macro ‘__careful_cmp’ + #define min(x, y) __careful_cmp(x, y, <) + ^~~~~~~~~~~~~ +../drivers/dma/imx-dma.c:288:8: note: in expansion of macro ‘min’ + now = min(d->len, sg_dma_len(sg)); + ^~~ + +Rework so that we use min_t and pass in the size_t that returns the +minimum of two values, using the specified type. + +Signed-off-by: Anders Roxell +Acked-by: Olof Johansson +Reviewed-by: Fabio Estevam +Signed-off-by: Vinod Koul +Signed-off-by: Sasha Levin +--- + drivers/dma/imx-dma.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/drivers/dma/imx-dma.c b/drivers/dma/imx-dma.c +index ddfd8024881e..f0182c5001ad 100644 +--- a/drivers/dma/imx-dma.c ++++ b/drivers/dma/imx-dma.c +@@ -291,7 +291,7 @@ static inline int imxdma_sg_next(struct imxdma_desc *d) + struct scatterlist *sg = d->sg; + unsigned long now; + +- now = min(d->len, sg_dma_len(sg)); ++ now = min_t(size_t, d->len, sg_dma_len(sg)); + if (d->len != IMX_DMA_LENGTH_LOOP) + d->len -= now; + +-- +2.19.1 + diff --git a/queue-3.18/dmaengine-tegra-avoid-overflow-of-byte-tracking.patch b/queue-3.18/dmaengine-tegra-avoid-overflow-of-byte-tracking.patch new file mode 100644 index 00000000000..29f6963812f --- /dev/null +++ b/queue-3.18/dmaengine-tegra-avoid-overflow-of-byte-tracking.patch @@ -0,0 +1,55 @@ +From 0ae99677f74045075ce3d48cba75817eb86d700f Mon Sep 17 00:00:00 2001 +From: Ben Dooks +Date: Wed, 21 Nov 2018 16:13:19 +0000 +Subject: dmaengine: tegra: avoid overflow of byte tracking + +[ Upstream commit e486df39305864604b7e25f2a95d51039517ac57 ] + +The dma_desc->bytes_transferred counter tracks the number of bytes +moved by the DMA channel. This is then used to calculate the information +passed back in the in the tegra_dma_tx_status callback, which is usually +fine. + +When the DMA channel is configured as continous, then the bytes_transferred +counter will increase over time and eventually overflow to become negative +so the residue count will become invalid and the ALSA sound-dma code will +report invalid hardware pointer values to the application. This results in +some users becoming confused about the playout position and putting audio +data in the wrong place. + +To fix this issue, always ensure the bytes_transferred field is modulo the +size of the request. We only do this for the case of the cyclic transfer +done ISR as anyone attempting to move 2GiB of DMA data in one transfer +is unlikely. + +Note, we don't fix the issue that we should /never/ transfer a negative +number of bytes so we could make those fields unsigned. + +Reviewed-by: Dmitry Osipenko +Signed-off-by: Ben Dooks +Acked-by: Jon Hunter +Signed-off-by: Vinod Koul +Signed-off-by: Sasha Levin +--- + drivers/dma/tegra20-apb-dma.c | 5 ++++- + 1 file changed, 4 insertions(+), 1 deletion(-) + +diff --git a/drivers/dma/tegra20-apb-dma.c b/drivers/dma/tegra20-apb-dma.c +index 16efa603ff65..8ebc43dbda3c 100644 +--- a/drivers/dma/tegra20-apb-dma.c ++++ b/drivers/dma/tegra20-apb-dma.c +@@ -613,7 +613,10 @@ static void handle_cont_sngl_cycle_dma_done(struct tegra_dma_channel *tdc, + + sgreq = list_first_entry(&tdc->pending_sg_req, typeof(*sgreq), node); + dma_desc = sgreq->dma_desc; +- dma_desc->bytes_transferred += sgreq->req_len; ++ /* if we dma for long enough the transfer count will wrap */ ++ dma_desc->bytes_transferred = ++ (dma_desc->bytes_transferred + sgreq->req_len) % ++ dma_desc->bytes_requested; + + /* Callback need to be call */ + if (!dma_desc->cb_count) +-- +2.19.1 + diff --git a/queue-3.18/drm-dp-mst-configure-no_stop_bit-correctly-for-remot.patch b/queue-3.18/drm-dp-mst-configure-no_stop_bit-correctly-for-remot.patch new file mode 100644 index 00000000000..e57df8aec13 --- /dev/null +++ b/queue-3.18/drm-dp-mst-configure-no_stop_bit-correctly-for-remot.patch @@ -0,0 +1,48 @@ +From 5aa5d4aede52a11d77f316cac019b839c4041909 Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= +Date: Fri, 28 Sep 2018 21:03:59 +0300 +Subject: drm/dp/mst: Configure no_stop_bit correctly for remote i2c xfers +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +[ Upstream commit c978ae9bde582e82a04c63a4071701691dd8b35c ] + +We aren't supposed to force a stop+start between every i2c msg +when performing multi message transfers. This should eg. cause +the DDC segment address to be reset back to 0 between writing +the segment address and reading the actual EDID extension block. + +To quote the E-DDC spec: +"... this standard requires that the segment pointer be + reset to 00h when a NO ACK or a STOP condition is received." + +Since we're going to touch this might as well consult the +I2C_M_STOP flag to determine whether we want to force the stop +or not. + +Cc: Brian Vincent +References: https://bugs.freedesktop.org/show_bug.cgi?id=108081 +Signed-off-by: Ville Syrjälä +Link: https://patchwork.freedesktop.org/patch/msgid/20180928180403.22499-1-ville.syrjala@linux.intel.com +Reviewed-by: Dhinakaran Pandiyan +Signed-off-by: Sasha Levin +--- + drivers/gpu/drm/drm_dp_mst_topology.c | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c b/drivers/gpu/drm/drm_dp_mst_topology.c +index 7113c95f5ad0..e4c8c594ea15 100644 +--- a/drivers/gpu/drm/drm_dp_mst_topology.c ++++ b/drivers/gpu/drm/drm_dp_mst_topology.c +@@ -2816,6 +2816,7 @@ static int drm_dp_mst_i2c_xfer(struct i2c_adapter *adapter, struct i2c_msg *msgs + msg.u.i2c_read.transactions[i].i2c_dev_id = msgs[i].addr; + msg.u.i2c_read.transactions[i].num_bytes = msgs[i].len; + msg.u.i2c_read.transactions[i].bytes = msgs[i].buf; ++ msg.u.i2c_read.transactions[i].no_stop_bit = !(msgs[i].flags & I2C_M_STOP); + } + msg.u.i2c_read.read_i2c_device_id = msgs[num - 1].addr; + msg.u.i2c_read.num_bytes_read = msgs[num - 1].len; +-- +2.19.1 + diff --git a/queue-3.18/e1000e-fix-cyclic-resets-at-link-up-with-active-tx.patch b/queue-3.18/e1000e-fix-cyclic-resets-at-link-up-with-active-tx.patch new file mode 100644 index 00000000000..d880eaa1c6b --- /dev/null +++ b/queue-3.18/e1000e-fix-cyclic-resets-at-link-up-with-active-tx.patch @@ -0,0 +1,91 @@ +From 16a5252a9f35ce7cf3e3f150ccef36cf2d2835a7 Mon Sep 17 00:00:00 2001 +From: Konstantin Khlebnikov +Date: Mon, 14 Jan 2019 16:29:30 +0300 +Subject: e1000e: fix cyclic resets at link up with active tx + +[ Upstream commit 0f9e980bf5ee1a97e2e401c846b2af989eb21c61 ] + +I'm seeing series of e1000e resets (sometimes endless) at system boot +if something generates tx traffic at this time. In my case this is +netconsole who sends message "e1000e 0000:02:00.0: Some CPU C-states +have been disabled in order to enable jumbo frames" from e1000e itself. +As result e1000_watchdog_task sees used tx buffer while carrier is off +and start this reset cycle again. + +[ 17.794359] e1000e: eth1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None +[ 17.794714] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready +[ 22.936455] e1000e 0000:02:00.0 eth1: changing MTU from 1500 to 9000 +[ 23.033336] e1000e 0000:02:00.0: Some CPU C-states have been disabled in order to enable jumbo frames +[ 26.102364] e1000e: eth1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None +[ 27.174495] 8021q: 802.1Q VLAN Support v1.8 +[ 27.174513] 8021q: adding VLAN 0 to HW filter on device eth1 +[ 30.671724] cgroup: cgroup: disabling cgroup2 socket matching due to net_prio or net_cls activation +[ 30.898564] netpoll: netconsole: local port 6666 +[ 30.898566] netpoll: netconsole: local IPv6 address 2a02:6b8:0:80b:beae:c5ff:fe28:23f8 +[ 30.898567] netpoll: netconsole: interface 'eth1' +[ 30.898568] netpoll: netconsole: remote port 6666 +[ 30.898568] netpoll: netconsole: remote IPv6 address 2a02:6b8:b000:605c:e61d:2dff:fe03:3790 +[ 30.898569] netpoll: netconsole: remote ethernet address b0:a8:6e:f4:ff:c0 +[ 30.917747] console [netcon0] enabled +[ 30.917749] netconsole: network logging started +[ 31.453353] e1000e 0000:02:00.0: Some CPU C-states have been disabled in order to enable jumbo frames +[ 34.185730] e1000e 0000:02:00.0: Some CPU C-states have been disabled in order to enable jumbo frames +[ 34.321840] e1000e 0000:02:00.0: Some CPU C-states have been disabled in order to enable jumbo frames +[ 34.465822] e1000e 0000:02:00.0: Some CPU C-states have been disabled in order to enable jumbo frames +[ 34.597423] e1000e 0000:02:00.0: Some CPU C-states have been disabled in order to enable jumbo frames +[ 34.745417] e1000e 0000:02:00.0: Some CPU C-states have been disabled in order to enable jumbo frames +[ 34.877356] e1000e 0000:02:00.0: Some CPU C-states have been disabled in order to enable jumbo frames +[ 35.005441] e1000e 0000:02:00.0: Some CPU C-states have been disabled in order to enable jumbo frames +[ 35.157376] e1000e 0000:02:00.0: Some CPU C-states have been disabled in order to enable jumbo frames +[ 35.289362] e1000e 0000:02:00.0: Some CPU C-states have been disabled in order to enable jumbo frames +[ 35.417441] e1000e 0000:02:00.0: Some CPU C-states have been disabled in order to enable jumbo frames +[ 37.790342] e1000e: eth1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None + +This patch flushes tx buffers only once when carrier is off +rather than at each watchdog iteration. + +Signed-off-by: Konstantin Khlebnikov +Tested-by: Aaron Brown +Signed-off-by: Jeff Kirsher +Signed-off-by: Sasha Levin +--- + drivers/net/ethernet/intel/e1000e/netdev.c | 15 ++++++--------- + 1 file changed, 6 insertions(+), 9 deletions(-) + +diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c b/drivers/net/ethernet/intel/e1000e/netdev.c +index ef5699103ec2..52920d036f49 100644 +--- a/drivers/net/ethernet/intel/e1000e/netdev.c ++++ b/drivers/net/ethernet/intel/e1000e/netdev.c +@@ -5073,8 +5073,13 @@ static void e1000_watchdog_task(struct work_struct *work) + /* 8000ES2LAN requires a Rx packet buffer work-around + * on link down event; reset the controller to flush + * the Rx packet buffer. ++ * ++ * If the link is lost the controller stops DMA, but ++ * if there is queued Tx work it cannot be done. So ++ * reset the controller to flush the Tx packet buffers. + */ +- if (adapter->flags & FLAG_RX_NEEDS_RESTART) ++ if ((adapter->flags & FLAG_RX_NEEDS_RESTART) || ++ e1000_desc_unused(tx_ring) + 1 < tx_ring->count) + adapter->flags |= FLAG_RESTART_NOW; + else + pm_schedule_suspend(netdev->dev.parent, +@@ -5097,14 +5102,6 @@ link_up: + adapter->gotc_old = adapter->stats.gotc; + spin_unlock(&adapter->stats64_lock); + +- /* If the link is lost the controller stops DMA, but +- * if there is queued Tx work it cannot be done. So +- * reset the controller to flush the Tx packet buffers. +- */ +- if (!netif_carrier_ok(netdev) && +- (e1000_desc_unused(tx_ring) + 1 < tx_ring->count)) +- adapter->flags |= FLAG_RESTART_NOW; +- + /* If reset is necessary, do it outside of interrupt context. */ + if (adapter->flags & FLAG_RESTART_NOW) { + schedule_work(&adapter->reset_task); +-- +2.19.1 + diff --git a/queue-3.18/e1000e-fix-wformat-truncation-warnings.patch b/queue-3.18/e1000e-fix-wformat-truncation-warnings.patch new file mode 100644 index 00000000000..fadbc235630 --- /dev/null +++ b/queue-3.18/e1000e-fix-wformat-truncation-warnings.patch @@ -0,0 +1,72 @@ +From ff80269362e48a26a01e8cac3be3c29881adc45f Mon Sep 17 00:00:00 2001 +From: Florian Fainelli +Date: Thu, 21 Feb 2019 20:09:28 -0800 +Subject: e1000e: Fix -Wformat-truncation warnings + +[ Upstream commit 135e7245479addc6b1f5d031e3d7e2ddb3d2b109 ] + +Provide precision hints to snprintf() since we know the destination +buffer size of the RX/TX ring names are IFNAMSIZ + 5 - 1. This fixes the +following warnings: + +drivers/net/ethernet/intel/e1000e/netdev.c: In function +'e1000_request_msix': +drivers/net/ethernet/intel/e1000e/netdev.c:2109:13: warning: 'snprintf' +output may be truncated before the last format character +[-Wformat-truncation=] + "%s-rx-0", netdev->name); + ^ +drivers/net/ethernet/intel/e1000e/netdev.c:2107:3: note: 'snprintf' +output between 6 and 21 bytes into a destination of size 20 + snprintf(adapter->rx_ring->name, + ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + sizeof(adapter->rx_ring->name) - 1, + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + "%s-rx-0", netdev->name); + ~~~~~~~~~~~~~~~~~~~~~~~~ +drivers/net/ethernet/intel/e1000e/netdev.c:2125:13: warning: 'snprintf' +output may be truncated before the last format character +[-Wformat-truncation=] + "%s-tx-0", netdev->name); + ^ +drivers/net/ethernet/intel/e1000e/netdev.c:2123:3: note: 'snprintf' +output between 6 and 21 bytes into a destination of size 20 + snprintf(adapter->tx_ring->name, + ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + sizeof(adapter->tx_ring->name) - 1, + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + "%s-tx-0", netdev->name); + ~~~~~~~~~~~~~~~~~~~~~~~~ + +Signed-off-by: Florian Fainelli +Signed-off-by: David S. Miller +Signed-off-by: Sasha Levin +--- + drivers/net/ethernet/intel/e1000e/netdev.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c b/drivers/net/ethernet/intel/e1000e/netdev.c +index 0beeebdc0c01..ef5699103ec2 100644 +--- a/drivers/net/ethernet/intel/e1000e/netdev.c ++++ b/drivers/net/ethernet/intel/e1000e/netdev.c +@@ -2132,7 +2132,7 @@ static int e1000_request_msix(struct e1000_adapter *adapter) + if (strlen(netdev->name) < (IFNAMSIZ - 5)) + snprintf(adapter->rx_ring->name, + sizeof(adapter->rx_ring->name) - 1, +- "%s-rx-0", netdev->name); ++ "%.14s-rx-0", netdev->name); + else + memcpy(adapter->rx_ring->name, netdev->name, IFNAMSIZ); + err = request_irq(adapter->msix_entries[vector].vector, +@@ -2148,7 +2148,7 @@ static int e1000_request_msix(struct e1000_adapter *adapter) + if (strlen(netdev->name) < (IFNAMSIZ - 5)) + snprintf(adapter->tx_ring->name, + sizeof(adapter->tx_ring->name) - 1, +- "%s-tx-0", netdev->name); ++ "%.14s-tx-0", netdev->name); + else + memcpy(adapter->tx_ring->name, netdev->name, IFNAMSIZ); + err = request_irq(adapter->msix_entries[vector].vector, +-- +2.19.1 + diff --git a/queue-3.18/fbdev-fbmem-fix-memory-access-if-logo-is-bigger-than.patch b/queue-3.18/fbdev-fbmem-fix-memory-access-if-logo-is-bigger-than.patch new file mode 100644 index 00000000000..156b3bc6ca7 --- /dev/null +++ b/queue-3.18/fbdev-fbmem-fix-memory-access-if-logo-is-bigger-than.patch @@ -0,0 +1,52 @@ +From 31f59baeb56d3826871f950ca0447b4b215bed91 Mon Sep 17 00:00:00 2001 +From: Manfred Schlaegl +Date: Fri, 8 Feb 2019 19:24:47 +0100 +Subject: fbdev: fbmem: fix memory access if logo is bigger than the screen + +[ Upstream commit a5399db139cb3ad9b8502d8b1bd02da9ce0b9df0 ] + +There is no clipping on the x or y axis for logos larger that the framebuffer +size. Therefore: a logo bigger than screen size leads to invalid memory access: + +[ 1.254664] Backtrace: +[ 1.254728] [] (cfb_imageblit) from [] (fb_show_logo+0x620/0x684) +[ 1.254763] r10:00000003 r9:00027fd8 r8:c6a40000 r7:c6a36e50 r6:00000000 r5:c06b81e4 +[ 1.254774] r4:c6a3e800 +[ 1.254810] [] (fb_show_logo) from [] (fbcon_switch+0x3fc/0x46c) +[ 1.254842] r10:c6a3e824 r9:c6a3e800 r8:00000000 r7:c6a0c000 r6:c070b014 r5:c6a3e800 +[ 1.254852] r4:c6808c00 +[ 1.254889] [] (fbcon_switch) from [] (redraw_screen+0xf0/0x1e8) +[ 1.254918] r10:00000000 r9:00000000 r8:00000000 r7:00000000 r6:c070d5a0 r5:00000080 +[ 1.254928] r4:c6808c00 +[ 1.254961] [] (redraw_screen) from [] (do_bind_con_driver+0x194/0x2e4) +[ 1.254991] r9:00000000 r8:00000000 r7:00000014 r6:c070d5a0 r5:c070d5a0 r4:c070d5a0 + +So prevent displaying a logo bigger than screen size and avoid invalid +memory access. + +Signed-off-by: Manfred Schlaegl +Signed-off-by: Martin Kepplinger +Cc: Daniel Vetter +Signed-off-by: Bartlomiej Zolnierkiewicz +Signed-off-by: Sasha Levin +--- + drivers/video/fbdev/core/fbmem.c | 3 +++ + 1 file changed, 3 insertions(+) + +diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c +index ea2bd6208a2f..9eae191728d2 100644 +--- a/drivers/video/fbdev/core/fbmem.c ++++ b/drivers/video/fbdev/core/fbmem.c +@@ -425,6 +425,9 @@ static void fb_do_show_logo(struct fb_info *info, struct fb_image *image, + { + unsigned int x; + ++ if (image->width > info->var.xres || image->height > info->var.yres) ++ return; ++ + if (rotate == FB_ROTATE_UR) { + for (x = 0; + x < num && image->dx + image->width <= info->var.xres; +-- +2.19.1 + diff --git a/queue-3.18/fs-fix-guard_bio_eod-to-check-for-real-eod-errors.patch b/queue-3.18/fs-fix-guard_bio_eod-to-check-for-real-eod-errors.patch new file mode 100644 index 00000000000..2c575b2a44e --- /dev/null +++ b/queue-3.18/fs-fix-guard_bio_eod-to-check-for-real-eod-errors.patch @@ -0,0 +1,79 @@ +From aebcc06f82f22055fffa0d3d90061b8f7a96e769 Mon Sep 17 00:00:00 2001 +From: Carlos Maiolino +Date: Tue, 26 Feb 2019 11:51:50 +0100 +Subject: fs: fix guard_bio_eod to check for real EOD errors + +[ Upstream commit dce30ca9e3b676fb288c33c1f4725a0621361185 ] + +guard_bio_eod() can truncate a segment in bio to allow it to do IO on +odd last sectors of a device. + +It already checks if the IO starts past EOD, but it does not consider +the possibility of an IO request starting within device boundaries can +contain more than one segment past EOD. + +In such cases, truncated_bytes can be bigger than PAGE_SIZE, and will +underflow bvec->bv_len. + +Fix this by checking if truncated_bytes is lower than PAGE_SIZE. + +This situation has been found on filesystems such as isofs and vfat, +which doesn't check the device size before mount, if the device is +smaller than the filesystem itself, a readahead on such filesystem, +which spans EOD, can trigger this situation, leading a call to +zero_user() with a wrong size possibly corrupting memory. + +I didn't see any crash, or didn't let the system run long enough to +check if memory corruption will be hit somewhere, but adding +instrumentation to guard_bio_end() to check truncated_bytes size, was +enough to see the error. + +The following script can trigger the error. + +MNT=/mnt +IMG=./DISK.img +DEV=/dev/loop0 + +mkfs.vfat $IMG +mount $IMG $MNT +cp -R /etc $MNT &> /dev/null +umount $MNT + +losetup -D + +losetup --find --show --sizelimit 16247280 $IMG +mount $DEV $MNT + +find $MNT -type f -exec cat {} + >/dev/null + +Kudos to Eric Sandeen for coming up with the reproducer above + +Reviewed-by: Ming Lei +Signed-off-by: Carlos Maiolino +Signed-off-by: Jens Axboe +Signed-off-by: Sasha Levin +--- + fs/buffer.c | 7 +++++++ + 1 file changed, 7 insertions(+) + +diff --git a/fs/buffer.c b/fs/buffer.c +index 20805db2c987..47b42e8ddca2 100644 +--- a/fs/buffer.c ++++ b/fs/buffer.c +@@ -2986,6 +2986,13 @@ void guard_bio_eod(int rw, struct bio *bio) + /* Uhhuh. We've got a bio that straddles the device size! */ + truncated_bytes = bio->bi_iter.bi_size - (maxsector << 9); + ++ /* ++ * The bio contains more than one segment which spans EOD, just return ++ * and let IO layer turn it into an EIO ++ */ ++ if (truncated_bytes > bvec->bv_len) ++ return; ++ + /* Truncate the bio.. */ + bio->bi_iter.bi_size -= truncated_bytes; + bvec->bv_len -= truncated_bytes; +-- +2.19.1 + diff --git a/queue-3.18/hpet-fix-missing-character-in-the-__setup-code-of-hp.patch b/queue-3.18/hpet-fix-missing-character-in-the-__setup-code-of-hp.patch new file mode 100644 index 00000000000..efead95e796 --- /dev/null +++ b/queue-3.18/hpet-fix-missing-character-in-the-__setup-code-of-hp.patch @@ -0,0 +1,59 @@ +From e1fddeae2b193493525b21028814d787cc15241b Mon Sep 17 00:00:00 2001 +From: Buland Singh +Date: Thu, 20 Dec 2018 17:35:24 +0530 +Subject: hpet: Fix missing '=' character in the __setup() code of + hpet_mmap_enable + +[ Upstream commit 24d48a61f2666630da130cc2ec2e526eacf229e3 ] + +Commit '3d035f580699 ("drivers/char/hpet.c: allow user controlled mmap for +user processes")' introduced a new kernel command line parameter hpet_mmap, +that is required to expose the memory map of the HPET registers to +user-space. Unfortunately the kernel command line parameter 'hpet_mmap' is +broken and never takes effect due to missing '=' character in the __setup() +code of hpet_mmap_enable. + +Before this patch: + +dmesg output with the kernel command line parameter hpet_mmap=1 + +[ 0.204152] HPET mmap disabled + +dmesg output with the kernel command line parameter hpet_mmap=0 + +[ 0.204192] HPET mmap disabled + +After this patch: + +dmesg output with the kernel command line parameter hpet_mmap=1 + +[ 0.203945] HPET mmap enabled + +dmesg output with the kernel command line parameter hpet_mmap=0 + +[ 0.204652] HPET mmap disabled + +Fixes: 3d035f580699 ("drivers/char/hpet.c: allow user controlled mmap for user processes") +Signed-off-by: Buland Singh +Signed-off-by: Greg Kroah-Hartman +Signed-off-by: Sasha Levin +--- + drivers/char/hpet.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/drivers/char/hpet.c b/drivers/char/hpet.c +index d5d4cd82b9f7..978a782f5e30 100644 +--- a/drivers/char/hpet.c ++++ b/drivers/char/hpet.c +@@ -377,7 +377,7 @@ static __init int hpet_mmap_enable(char *str) + pr_info("HPET mmap %s\n", hpet_mmap_enabled ? "enabled" : "disabled"); + return 1; + } +-__setup("hpet_mmap", hpet_mmap_enable); ++__setup("hpet_mmap=", hpet_mmap_enable); + + static int hpet_mmap(struct file *file, struct vm_area_struct *vma) + { +-- +2.19.1 + diff --git a/queue-3.18/hwrng-virtio-avoid-repeated-init-of-completion.patch b/queue-3.18/hwrng-virtio-avoid-repeated-init-of-completion.patch new file mode 100644 index 00000000000..752485ee866 --- /dev/null +++ b/queue-3.18/hwrng-virtio-avoid-repeated-init-of-completion.patch @@ -0,0 +1,57 @@ +From 0630163ea843d0f3fa8a45668b82c2789005cb53 Mon Sep 17 00:00:00 2001 +From: David Tolnay +Date: Mon, 7 Jan 2019 14:36:11 -0800 +Subject: hwrng: virtio - Avoid repeated init of completion + +[ Upstream commit aef027db48da56b6f25d0e54c07c8401ada6ce21 ] + +The virtio-rng driver uses a completion called have_data to wait for a +virtio read to be fulfilled by the hypervisor. The completion is reset +before placing a buffer on the virtio queue and completed by the virtio +callback once data has been written into the buffer. + +Prior to this commit, the driver called init_completion on this +completion both during probe as well as when registering virtio buffers +as part of a hwrng read operation. The second of these init_completion +calls should instead be reinit_completion because the have_data +completion has already been inited by probe. As described in +Documentation/scheduler/completion.txt, "Calling init_completion() twice +on the same completion object is most likely a bug". + +This bug was present in the initial implementation of virtio-rng in +f7f510ec1957 ("virtio: An entropy device, as suggested by hpa"). Back +then the have_data completion was a single static completion rather than +a member of one of potentially multiple virtrng_info structs as +implemented later by 08e53fbdb85c ("virtio-rng: support multiple +virtio-rng devices"). The original driver incorrectly used +init_completion rather than INIT_COMPLETION to reset have_data during +read. + +Tested by running `head -c48 /dev/random | hexdump` within crosvm, the +Chrome OS virtual machine monitor, and confirming that the virtio-rng +driver successfully produces random bytes from the host. + +Signed-off-by: David Tolnay +Tested-by: David Tolnay +Signed-off-by: Herbert Xu +Signed-off-by: Sasha Levin +--- + drivers/char/hw_random/virtio-rng.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/drivers/char/hw_random/virtio-rng.c b/drivers/char/hw_random/virtio-rng.c +index 72295ea2fd1c..5cdc8c534ad4 100644 +--- a/drivers/char/hw_random/virtio-rng.c ++++ b/drivers/char/hw_random/virtio-rng.c +@@ -74,7 +74,7 @@ static int virtio_read(struct hwrng *rng, void *buf, size_t size, bool wait) + + if (!vi->busy) { + vi->busy = true; +- init_completion(&vi->have_data); ++ reinit_completion(&vi->have_data); + register_buffer(vi, buf, size); + } + +-- +2.19.1 + diff --git a/queue-3.18/ib-mlx4-increase-the-timeout-for-cm-cache.patch b/queue-3.18/ib-mlx4-increase-the-timeout-for-cm-cache.patch new file mode 100644 index 00000000000..97de2776cec --- /dev/null +++ b/queue-3.18/ib-mlx4-increase-the-timeout-for-cm-cache.patch @@ -0,0 +1,106 @@ +From 6d33fad03657048e7dc3eb10cdba8c2d8c4ccbfa Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?H=C3=A5kon=20Bugge?= +Date: Sun, 17 Feb 2019 15:45:12 +0100 +Subject: IB/mlx4: Increase the timeout for CM cache +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +[ Upstream commit 2612d723aadcf8281f9bf8305657129bd9f3cd57 ] + +Using CX-3 virtual functions, either from a bare-metal machine or +pass-through from a VM, MAD packets are proxied through the PF driver. + +Since the VF drivers have separate name spaces for MAD Transaction Ids +(TIDs), the PF driver has to re-map the TIDs and keep the book keeping +in a cache. + +Following the RDMA Connection Manager (CM) protocol, it is clear when +an entry has to evicted form the cache. But life is not perfect, +remote peers may die or be rebooted. Hence, it's a timeout to wipe out +a cache entry, when the PF driver assumes the remote peer has gone. + +During workloads where a high number of QPs are destroyed concurrently, +excessive amount of CM DREQ retries has been observed + +The problem can be demonstrated in a bare-metal environment, where two +nodes have instantiated 8 VFs each. This using dual ported HCAs, so we +have 16 vPorts per physical server. + +64 processes are associated with each vPort and creates and destroys +one QP for each of the remote 64 processes. That is, 1024 QPs per +vPort, all in all 16K QPs. The QPs are created/destroyed using the +CM. + +When tearing down these 16K QPs, excessive CM DREQ retries (and +duplicates) are observed. With some cat/paste/awk wizardry on the +infiniband_cm sysfs, we observe as sum of the 16 vPorts on one of the +nodes: + +cm_rx_duplicates: + dreq 2102 +cm_rx_msgs: + drep 1989 + dreq 6195 + rep 3968 + req 4224 + rtu 4224 +cm_tx_msgs: + drep 4093 + dreq 27568 + rep 4224 + req 3968 + rtu 3968 +cm_tx_retries: + dreq 23469 + +Note that the active/passive side is equally distributed between the +two nodes. + +Enabling pr_debug in cm.c gives tons of: + +[171778.814239] mlx4_ib_multiplex_cm_handler: id{slave: +1,sl_cm_id: 0xd393089f} is NULL! + +By increasing the CM_CLEANUP_CACHE_TIMEOUT from 5 to 30 seconds, the +tear-down phase of the application is reduced from approximately 90 to +50 seconds. Retries/duplicates are also significantly reduced: + +cm_rx_duplicates: + dreq 2460 +[] +cm_tx_retries: + dreq 3010 + req 47 + +Increasing the timeout further didn't help, as these duplicates and +retries stems from a too short CMA timeout, which was 20 (~4 seconds) +on the systems. By increasing the CMA timeout to 22 (~17 seconds), the +numbers fell down to about 10 for both of them. + +Adjustment of the CMA timeout is not part of this commit. + +Signed-off-by: HÃ¥kon Bugge +Acked-by: Jack Morgenstein +Signed-off-by: Jason Gunthorpe +Signed-off-by: Sasha Levin +--- + drivers/infiniband/hw/mlx4/cm.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/drivers/infiniband/hw/mlx4/cm.c b/drivers/infiniband/hw/mlx4/cm.c +index 56a593e0ae5d..2aedbd18ffbc 100644 +--- a/drivers/infiniband/hw/mlx4/cm.c ++++ b/drivers/infiniband/hw/mlx4/cm.c +@@ -39,7 +39,7 @@ + + #include "mlx4_ib.h" + +-#define CM_CLEANUP_CACHE_TIMEOUT (5 * HZ) ++#define CM_CLEANUP_CACHE_TIMEOUT (30 * HZ) + + struct id_map_entry { + struct rb_node node; +-- +2.19.1 + diff --git a/queue-3.18/kprobes-prohibit-probing-on-bsearch.patch b/queue-3.18/kprobes-prohibit-probing-on-bsearch.patch new file mode 100644 index 00000000000..10fdfcc9937 --- /dev/null +++ b/queue-3.18/kprobes-prohibit-probing-on-bsearch.patch @@ -0,0 +1,56 @@ +From d90fa2cbabcd6fe2a1dfec45485fa87150cd5ca5 Mon Sep 17 00:00:00 2001 +From: Andrea Righi +Date: Wed, 13 Feb 2019 01:15:34 +0900 +Subject: kprobes: Prohibit probing on bsearch() + +[ Upstream commit 02106f883cd745523f7766d90a739f983f19e650 ] + +Since kprobe breakpoing handler is using bsearch(), probing on this +routine can cause recursive breakpoint problem. + +int3 + ->do_int3() + ->ftrace_int3_handler() + ->ftrace_location() + ->ftrace_location_range() + ->bsearch() -> int3 + +Prohibit probing on bsearch(). + +Signed-off-by: Andrea Righi +Acked-by: Masami Hiramatsu +Cc: Alexander Shishkin +Cc: Arnaldo Carvalho de Melo +Cc: Jiri Olsa +Cc: Linus Torvalds +Cc: Mathieu Desnoyers +Cc: Peter Zijlstra +Cc: Steven Rostedt +Cc: Thomas Gleixner +Link: http://lkml.kernel.org/r/154998813406.31052.8791425358974650922.stgit@devbox +Signed-off-by: Ingo Molnar +Signed-off-by: Sasha Levin +--- + lib/bsearch.c | 2 ++ + 1 file changed, 2 insertions(+) + +diff --git a/lib/bsearch.c b/lib/bsearch.c +index e33c179089db..d50048446b77 100644 +--- a/lib/bsearch.c ++++ b/lib/bsearch.c +@@ -11,6 +11,7 @@ + + #include + #include ++#include + + /* + * bsearch - binary search an array of elements +@@ -51,3 +52,4 @@ void *bsearch(const void *key, const void *base, size_t num, size_t size, + return NULL; + } + EXPORT_SYMBOL(bsearch); ++NOKPROBE_SYMBOL(bsearch); +-- +2.19.1 + diff --git a/queue-3.18/leds-lp55xx-fix-null-deref-on-firmware-load-failure.patch b/queue-3.18/leds-lp55xx-fix-null-deref-on-firmware-load-failure.patch new file mode 100644 index 00000000000..4dfc7f47a44 --- /dev/null +++ b/queue-3.18/leds-lp55xx-fix-null-deref-on-firmware-load-failure.patch @@ -0,0 +1,58 @@ +From f3c5a1618c1394844bf73932ddae7a2391883209 Mon Sep 17 00:00:00 2001 +From: Michal Kazior +Date: Mon, 11 Feb 2019 10:29:27 +0100 +Subject: leds: lp55xx: fix null deref on firmware load failure + +[ Upstream commit 5ddb0869bfc1bca6cfc592c74c64a026f936638c ] + +I've stumbled upon a kernel crash and the logs +pointed me towards the lp5562 driver: + +> <4>[306013.841294] lp5562 0-0030: Direct firmware load for lp5562 failed with error -2 +> <4>[306013.894990] lp5562 0-0030: Falling back to user helper +> ... +> <3>[306073.924886] lp5562 0-0030: firmware request failed +> <1>[306073.939456] Unable to handle kernel NULL pointer dereference at virtual address 00000000 +> <4>[306074.251011] PC is at _raw_spin_lock+0x1c/0x58 +> <4>[306074.255539] LR is at release_firmware+0x6c/0x138 +> ... + +After taking a look I noticed firmware_release() +could be called with either NULL or a dangling +pointer. + +Fixes: 10c06d178df11 ("leds-lp55xx: support firmware interface") +Signed-off-by: Michal Kazior +Signed-off-by: Jacek Anaszewski +Signed-off-by: Sasha Levin +--- + drivers/leds/leds-lp55xx-common.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +diff --git a/drivers/leds/leds-lp55xx-common.c b/drivers/leds/leds-lp55xx-common.c +index 77c26bc32eed..a038f1128446 100644 +--- a/drivers/leds/leds-lp55xx-common.c ++++ b/drivers/leds/leds-lp55xx-common.c +@@ -200,7 +200,7 @@ static void lp55xx_firmware_loaded(const struct firmware *fw, void *context) + + if (!fw) { + dev_err(dev, "firmware request failed\n"); +- goto out; ++ return; + } + + /* handling firmware data is chip dependent */ +@@ -213,9 +213,9 @@ static void lp55xx_firmware_loaded(const struct firmware *fw, void *context) + + mutex_unlock(&chip->lock); + +-out: + /* firmware should be released for other channel use */ + release_firmware(chip->fw); ++ chip->fw = NULL; + } + + static int lp55xx_request_firmware(struct lp55xx_chip *chip) +-- +2.19.1 + diff --git a/queue-3.18/locking-lockdep-add-debug_locks-check-in-__lock_down.patch b/queue-3.18/locking-lockdep-add-debug_locks-check-in-__lock_down.patch new file mode 100644 index 00000000000..e864ea15d05 --- /dev/null +++ b/queue-3.18/locking-lockdep-add-debug_locks-check-in-__lock_down.patch @@ -0,0 +1,50 @@ +From b657782c668303713770ef97587a10335ae4aa76 Mon Sep 17 00:00:00 2001 +From: Waiman Long +Date: Wed, 9 Jan 2019 23:03:25 -0500 +Subject: locking/lockdep: Add debug_locks check in __lock_downgrade() + +[ Upstream commit 71492580571467fb7177aade19c18ce7486267f5 ] + +Tetsuo Handa had reported he saw an incorrect "downgrading a read lock" +warning right after a previous lockdep warning. It is likely that the +previous warning turned off lock debugging causing the lockdep to have +inconsistency states leading to the lock downgrade warning. + +Fix that by add a check for debug_locks at the beginning of +__lock_downgrade(). + +Debugged-by: Tetsuo Handa +Reported-by: Tetsuo Handa +Reported-by: syzbot+53383ae265fb161ef488@syzkaller.appspotmail.com +Signed-off-by: Waiman Long +Signed-off-by: Peter Zijlstra (Intel) +Cc: Andrew Morton +Cc: Linus Torvalds +Cc: Paul E. McKenney +Cc: Peter Zijlstra +Cc: Thomas Gleixner +Cc: Will Deacon +Link: https://lkml.kernel.org/r/1547093005-26085-1-git-send-email-longman@redhat.com +Signed-off-by: Ingo Molnar +Signed-off-by: Sasha Levin +--- + kernel/locking/lockdep.c | 3 +++ + 1 file changed, 3 insertions(+) + +diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c +index fb90ca3a296e..27de98428367 100644 +--- a/kernel/locking/lockdep.c ++++ b/kernel/locking/lockdep.c +@@ -3312,6 +3312,9 @@ __lock_set_class(struct lockdep_map *lock, const char *name, + unsigned int depth; + int i; + ++ if (unlikely(!debug_locks)) ++ return 0; ++ + depth = curr->lockdep_depth; + /* + * This function is about (re)setting the class of a held lock, +-- +2.19.1 + diff --git a/queue-3.18/media-mt9m111-set-initial-frame-size-other-than-0x0.patch b/queue-3.18/media-mt9m111-set-initial-frame-size-other-than-0x0.patch new file mode 100644 index 00000000000..37d87889949 --- /dev/null +++ b/queue-3.18/media-mt9m111-set-initial-frame-size-other-than-0x0.patch @@ -0,0 +1,39 @@ +From 3b9af2d35f291750a4caad5c79c93b088380705c Mon Sep 17 00:00:00 2001 +From: Akinobu Mita +Date: Tue, 15 Jan 2019 12:05:41 -0200 +Subject: media: mt9m111: set initial frame size other than 0x0 + +[ Upstream commit 29856308137de1c21eda89411695f4fc6e9780ff ] + +This driver sets initial frame width and height to 0x0, which is invalid. +So set it to selection rectangle bounds instead. + +This is detected by v4l2-compliance detected. + +Cc: Enrico Scholz +Cc: Michael Grzeschik +Cc: Marco Felsch +Signed-off-by: Akinobu Mita +Signed-off-by: Sakari Ailus +Signed-off-by: Mauro Carvalho Chehab +Signed-off-by: Sasha Levin +--- + drivers/media/i2c/soc_camera/mt9m111.c | 2 ++ + 1 file changed, 2 insertions(+) + +diff --git a/drivers/media/i2c/soc_camera/mt9m111.c b/drivers/media/i2c/soc_camera/mt9m111.c +index b51e8562e775..1ee437e9cfcb 100644 +--- a/drivers/media/i2c/soc_camera/mt9m111.c ++++ b/drivers/media/i2c/soc_camera/mt9m111.c +@@ -983,6 +983,8 @@ static int mt9m111_probe(struct i2c_client *client, + mt9m111->rect.top = MT9M111_MIN_DARK_ROWS; + mt9m111->rect.width = MT9M111_MAX_WIDTH; + mt9m111->rect.height = MT9M111_MAX_HEIGHT; ++ mt9m111->width = mt9m111->rect.width; ++ mt9m111->height = mt9m111->rect.height; + mt9m111->fmt = &mt9m111_colour_fmts[0]; + mt9m111->lastpage = -1; + mutex_init(&mt9m111->power_lock); +-- +2.19.1 + diff --git a/queue-3.18/media-s5p-jpeg-check-for-fmt_ver_flag-when-doing-fmt.patch b/queue-3.18/media-s5p-jpeg-check-for-fmt_ver_flag-when-doing-fmt.patch new file mode 100644 index 00000000000..778019f4781 --- /dev/null +++ b/queue-3.18/media-s5p-jpeg-check-for-fmt_ver_flag-when-doing-fmt.patch @@ -0,0 +1,86 @@ +From bb5540dedc46c3b985e4620dc4a658c77a54b046 Mon Sep 17 00:00:00 2001 +From: Pawe? Chmiel +Date: Sat, 29 Dec 2018 10:46:01 -0500 +Subject: media: s5p-jpeg: Check for fmt_ver_flag when doing fmt enumeration + +[ Upstream commit 49710c32cd9d6626a77c9f5f978a5f58cb536b35 ] + +Previously when doing format enumeration, it was returning all + formats supported by driver, even if they're not supported by hw. +Add missing check for fmt_ver_flag, so it'll be fixed and only those + supported by hw will be returned. Similar thing is already done + in s5p_jpeg_find_format. + +It was found by using v4l2-compliance tool and checking result + of VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS test +and using v4l2-ctl to get list of all supported formats. + +Tested on s5pv210-galaxys (Samsung i9000 phone). + +Fixes: bb677f3ac434 ("[media] Exynos4 JPEG codec v4l2 driver") + +Signed-off-by: Pawe? Chmiel +Reviewed-by: Jacek Anaszewski +[hverkuil-cisco@xs4all.nl: fix a few alignment issues] +Signed-off-by: Mauro Carvalho Chehab +Signed-off-by: Sasha Levin +--- + drivers/media/platform/s5p-jpeg/jpeg-core.c | 19 +++++++++++-------- + 1 file changed, 11 insertions(+), 8 deletions(-) + +diff --git a/drivers/media/platform/s5p-jpeg/jpeg-core.c b/drivers/media/platform/s5p-jpeg/jpeg-core.c +index 6fcc7f072ace..480266e01037 100644 +--- a/drivers/media/platform/s5p-jpeg/jpeg-core.c ++++ b/drivers/media/platform/s5p-jpeg/jpeg-core.c +@@ -1011,13 +1011,16 @@ static int s5p_jpeg_querycap(struct file *file, void *priv, + return 0; + } + +-static int enum_fmt(struct s5p_jpeg_fmt *sjpeg_formats, int n, ++static int enum_fmt(struct s5p_jpeg_ctx *ctx, ++ struct s5p_jpeg_fmt *sjpeg_formats, int n, + struct v4l2_fmtdesc *f, u32 type) + { + int i, num = 0; ++ unsigned int fmt_ver_flag = ctx->jpeg->variant->fmt_ver_flag; + + for (i = 0; i < n; ++i) { +- if (sjpeg_formats[i].flags & type) { ++ if (sjpeg_formats[i].flags & type && ++ sjpeg_formats[i].flags & fmt_ver_flag) { + /* index-th format of type type found ? */ + if (num == f->index) + break; +@@ -1043,11 +1046,11 @@ static int s5p_jpeg_enum_fmt_vid_cap(struct file *file, void *priv, + struct s5p_jpeg_ctx *ctx = fh_to_ctx(priv); + + if (ctx->mode == S5P_JPEG_ENCODE) +- return enum_fmt(sjpeg_formats, SJPEG_NUM_FORMATS, f, ++ return enum_fmt(ctx, sjpeg_formats, SJPEG_NUM_FORMATS, f, + SJPEG_FMT_FLAG_ENC_CAPTURE); + +- return enum_fmt(sjpeg_formats, SJPEG_NUM_FORMATS, f, +- SJPEG_FMT_FLAG_DEC_CAPTURE); ++ return enum_fmt(ctx, sjpeg_formats, SJPEG_NUM_FORMATS, f, ++ SJPEG_FMT_FLAG_DEC_CAPTURE); + } + + static int s5p_jpeg_enum_fmt_vid_out(struct file *file, void *priv, +@@ -1056,11 +1059,11 @@ static int s5p_jpeg_enum_fmt_vid_out(struct file *file, void *priv, + struct s5p_jpeg_ctx *ctx = fh_to_ctx(priv); + + if (ctx->mode == S5P_JPEG_ENCODE) +- return enum_fmt(sjpeg_formats, SJPEG_NUM_FORMATS, f, ++ return enum_fmt(ctx, sjpeg_formats, SJPEG_NUM_FORMATS, f, + SJPEG_FMT_FLAG_ENC_OUTPUT); + +- return enum_fmt(sjpeg_formats, SJPEG_NUM_FORMATS, f, +- SJPEG_FMT_FLAG_DEC_OUTPUT); ++ return enum_fmt(ctx, sjpeg_formats, SJPEG_NUM_FORMATS, f, ++ SJPEG_FMT_FLAG_DEC_OUTPUT); + } + + static struct s5p_jpeg_q_data *get_q_data(struct s5p_jpeg_ctx *ctx, +-- +2.19.1 + diff --git a/queue-3.18/mm-cma.c-cma_declare_contiguous-correct-err-handling.patch b/queue-3.18/mm-cma.c-cma_declare_contiguous-correct-err-handling.patch new file mode 100644 index 00000000000..e8e23839c52 --- /dev/null +++ b/queue-3.18/mm-cma.c-cma_declare_contiguous-correct-err-handling.patch @@ -0,0 +1,59 @@ +From 92e1020221bcb15c209e35deb92d7bd72d179955 Mon Sep 17 00:00:00 2001 +From: Peng Fan +Date: Tue, 5 Mar 2019 15:49:50 -0800 +Subject: mm/cma.c: cma_declare_contiguous: correct err handling + +[ Upstream commit 0d3bd18a5efd66097ef58622b898d3139790aa9d ] + +In case cma_init_reserved_mem failed, need to free the memblock +allocated by memblock_reserve or memblock_alloc_range. + +Quote Catalin's comments: + https://lkml.org/lkml/2019/2/26/482 + +Kmemleak is supposed to work with the memblock_{alloc,free} pair and it +ignores the memblock_reserve() as a memblock_alloc() implementation +detail. It is, however, tolerant to memblock_free() being called on +a sub-range or just a different range from a previous memblock_alloc(). +So the original patch looks fine to me. FWIW: + +Link: http://lkml.kernel.org/r/20190227144631.16708-1-peng.fan@nxp.com +Signed-off-by: Peng Fan +Reviewed-by: Catalin Marinas +Reviewed-by: Mike Rapoport +Cc: Laura Abbott +Cc: Joonsoo Kim +Cc: Michal Hocko +Cc: Vlastimil Babka +Cc: Marek Szyprowski +Cc: Andrey Konovalov +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Sasha Levin +--- + mm/cma.c | 4 +++- + 1 file changed, 3 insertions(+), 1 deletion(-) + +diff --git a/mm/cma.c b/mm/cma.c +index 7d266e393c44..1f4a7e076a5c 100644 +--- a/mm/cma.c ++++ b/mm/cma.c +@@ -340,12 +340,14 @@ int __init cma_declare_contiguous(phys_addr_t base, + + ret = cma_init_reserved_mem(base, size, order_per_bit, res_cma); + if (ret) +- goto err; ++ goto free_mem; + + pr_info("Reserved %ld MiB at %pa\n", (unsigned long)size / SZ_1M, + &base); + return 0; + ++free_mem: ++ memblock_free(base, size); + err: + pr_err("Failed to reserve %ld MiB\n", (unsigned long)size / SZ_1M); + return ret; +-- +2.19.1 + diff --git a/queue-3.18/mm-slab.c-kmemleak-no-scan-alien-caches.patch b/queue-3.18/mm-slab.c-kmemleak-no-scan-alien-caches.patch new file mode 100644 index 00000000000..dc617d1b6a4 --- /dev/null +++ b/queue-3.18/mm-slab.c-kmemleak-no-scan-alien-caches.patch @@ -0,0 +1,151 @@ +From fccb9661bfd2585cec04f0d2b2725d461b579a96 Mon Sep 17 00:00:00 2001 +From: Qian Cai +Date: Tue, 5 Mar 2019 15:42:03 -0800 +Subject: mm/slab.c: kmemleak no scan alien caches + +[ Upstream commit 92d1d07daad65c300c7d0b68bbef8867e9895d54 ] + +Kmemleak throws endless warnings during boot due to in +__alloc_alien_cache(), + + alc = kmalloc_node(memsize, gfp, node); + init_arraycache(&alc->ac, entries, batch); + kmemleak_no_scan(ac); + +Kmemleak does not track the array cache (alc->ac) but the alien cache +(alc) instead, so let it track the latter by lifting kmemleak_no_scan() +out of init_arraycache(). + +There is another place that calls init_arraycache(), but +alloc_kmem_cache_cpus() uses the percpu allocation where will never be +considered as a leak. + + kmemleak: Found object by alias at 0xffff8007b9aa7e38 + CPU: 190 PID: 1 Comm: swapper/0 Not tainted 5.0.0-rc2+ #2 + Call trace: + dump_backtrace+0x0/0x168 + show_stack+0x24/0x30 + dump_stack+0x88/0xb0 + lookup_object+0x84/0xac + find_and_get_object+0x84/0xe4 + kmemleak_no_scan+0x74/0xf4 + setup_kmem_cache_node+0x2b4/0x35c + __do_tune_cpucache+0x250/0x2d4 + do_tune_cpucache+0x4c/0xe4 + enable_cpucache+0xc8/0x110 + setup_cpu_cache+0x40/0x1b8 + __kmem_cache_create+0x240/0x358 + create_cache+0xc0/0x198 + kmem_cache_create_usercopy+0x158/0x20c + kmem_cache_create+0x50/0x64 + fsnotify_init+0x58/0x6c + do_one_initcall+0x194/0x388 + kernel_init_freeable+0x668/0x688 + kernel_init+0x18/0x124 + ret_from_fork+0x10/0x18 + kmemleak: Object 0xffff8007b9aa7e00 (size 256): + kmemleak: comm "swapper/0", pid 1, jiffies 4294697137 + kmemleak: min_count = 1 + kmemleak: count = 0 + kmemleak: flags = 0x1 + kmemleak: checksum = 0 + kmemleak: backtrace: + kmemleak_alloc+0x84/0xb8 + kmem_cache_alloc_node_trace+0x31c/0x3a0 + __kmalloc_node+0x58/0x78 + setup_kmem_cache_node+0x26c/0x35c + __do_tune_cpucache+0x250/0x2d4 + do_tune_cpucache+0x4c/0xe4 + enable_cpucache+0xc8/0x110 + setup_cpu_cache+0x40/0x1b8 + __kmem_cache_create+0x240/0x358 + create_cache+0xc0/0x198 + kmem_cache_create_usercopy+0x158/0x20c + kmem_cache_create+0x50/0x64 + fsnotify_init+0x58/0x6c + do_one_initcall+0x194/0x388 + kernel_init_freeable+0x668/0x688 + kernel_init+0x18/0x124 + kmemleak: Not scanning unknown object at 0xffff8007b9aa7e38 + CPU: 190 PID: 1 Comm: swapper/0 Not tainted 5.0.0-rc2+ #2 + Call trace: + dump_backtrace+0x0/0x168 + show_stack+0x24/0x30 + dump_stack+0x88/0xb0 + kmemleak_no_scan+0x90/0xf4 + setup_kmem_cache_node+0x2b4/0x35c + __do_tune_cpucache+0x250/0x2d4 + do_tune_cpucache+0x4c/0xe4 + enable_cpucache+0xc8/0x110 + setup_cpu_cache+0x40/0x1b8 + __kmem_cache_create+0x240/0x358 + create_cache+0xc0/0x198 + kmem_cache_create_usercopy+0x158/0x20c + kmem_cache_create+0x50/0x64 + fsnotify_init+0x58/0x6c + do_one_initcall+0x194/0x388 + kernel_init_freeable+0x668/0x688 + kernel_init+0x18/0x124 + ret_from_fork+0x10/0x18 + +Link: http://lkml.kernel.org/r/20190129184518.39808-1-cai@lca.pw +Fixes: 1fe00d50a9e8 ("slab: factor out initialization of array cache") +Signed-off-by: Qian Cai +Reviewed-by: Andrew Morton +Cc: Christoph Lameter +Cc: Pekka Enberg +Cc: David Rientjes +Cc: Joonsoo Kim +Cc: Catalin Marinas +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Sasha Levin +--- + mm/slab.c | 17 +++++++++-------- + 1 file changed, 9 insertions(+), 8 deletions(-) + +diff --git a/mm/slab.c b/mm/slab.c +index 208b24a4d423..f29925d7a52e 100644 +--- a/mm/slab.c ++++ b/mm/slab.c +@@ -659,14 +659,6 @@ static void start_cpu_timer(int cpu) + + static void init_arraycache(struct array_cache *ac, int limit, int batch) + { +- /* +- * The array_cache structures contain pointers to free object. +- * However, when such objects are allocated or transferred to another +- * cache the pointers are not cleared and they could be counted as +- * valid references during a kmemleak scan. Therefore, kmemleak must +- * not scan such objects. +- */ +- kmemleak_no_scan(ac); + if (ac) { + ac->avail = 0; + ac->limit = limit; +@@ -682,6 +674,14 @@ static struct array_cache *alloc_arraycache(int node, int entries, + struct array_cache *ac = NULL; + + ac = kmalloc_node(memsize, gfp, node); ++ /* ++ * The array_cache structures contain pointers to free object. ++ * However, when such objects are allocated or transferred to another ++ * cache the pointers are not cleared and they could be counted as ++ * valid references during a kmemleak scan. Therefore, kmemleak must ++ * not scan such objects. ++ */ ++ kmemleak_no_scan(ac); + init_arraycache(ac, entries, batchcount); + return ac; + } +@@ -870,6 +870,7 @@ static struct alien_cache *__alloc_alien_cache(int node, int entries, + + alc = kmalloc_node(memsize, gfp, node); + if (alc) { ++ kmemleak_no_scan(alc); + init_arraycache(&alc->ac, entries, batch); + spin_lock_init(&alc->lock); + } +-- +2.19.1 + diff --git a/queue-3.18/mm-vmalloc.c-fix-kernel-bug-at-mm-vmalloc.c-512.patch b/queue-3.18/mm-vmalloc.c-fix-kernel-bug-at-mm-vmalloc.c-512.patch new file mode 100644 index 00000000000..9c2482d1746 --- /dev/null +++ b/queue-3.18/mm-vmalloc.c-fix-kernel-bug-at-mm-vmalloc.c-512.patch @@ -0,0 +1,62 @@ +From 3d0bfeada37e9d3a6ea0ab089d8c2ebec01010e6 Mon Sep 17 00:00:00 2001 +From: "Uladzislau Rezki (Sony)" +Date: Tue, 5 Mar 2019 15:45:59 -0800 +Subject: mm/vmalloc.c: fix kernel BUG at mm/vmalloc.c:512! + +[ Upstream commit afd07389d3f4933c7f7817a92fb5e053d59a3182 ] + +One of the vmalloc stress test case triggers the kernel BUG(): + + + [60.562151] ------------[ cut here ]------------ + [60.562154] kernel BUG at mm/vmalloc.c:512! + [60.562206] invalid opcode: 0000 [#1] PREEMPT SMP PTI + [60.562247] CPU: 0 PID: 430 Comm: vmalloc_test/0 Not tainted 4.20.0+ #161 + [60.562293] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014 + [60.562351] RIP: 0010:alloc_vmap_area+0x36f/0x390 + + +it can happen due to big align request resulting in overflowing of +calculated address, i.e. it becomes 0 after ALIGN()'s fixup. + +Fix it by checking if calculated address is within vstart/vend range. + +Link: http://lkml.kernel.org/r/20190124115648.9433-2-urezki@gmail.com +Signed-off-by: Uladzislau Rezki (Sony) +Reviewed-by: Andrew Morton +Cc: Ingo Molnar +Cc: Joel Fernandes +Cc: Matthew Wilcox +Cc: Michal Hocko +Cc: Oleksiy Avramchenko +Cc: Steven Rostedt +Cc: Tejun Heo +Cc: Thomas Garnier +Cc: Thomas Gleixner +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Sasha Levin +--- + mm/vmalloc.c | 6 +++++- + 1 file changed, 5 insertions(+), 1 deletion(-) + +diff --git a/mm/vmalloc.c b/mm/vmalloc.c +index 33920fc41d6b..fbb00e0d4c56 100644 +--- a/mm/vmalloc.c ++++ b/mm/vmalloc.c +@@ -439,7 +439,11 @@ nocache: + } + + found: +- if (addr + size > vend) ++ /* ++ * Check also calculated address against the vstart, ++ * because it can be 0 because of big align request. ++ */ ++ if (addr + size > vend || addr < vstart) + goto overflow; + + va->va_start = addr; +-- +2.19.1 + diff --git a/queue-3.18/mmc-omap-fix-the-maximum-timeout-setting.patch b/queue-3.18/mmc-omap-fix-the-maximum-timeout-setting.patch new file mode 100644 index 00000000000..52720c74187 --- /dev/null +++ b/queue-3.18/mmc-omap-fix-the-maximum-timeout-setting.patch @@ -0,0 +1,51 @@ +From f4c403a5bab34857b1d6e157b5e33cc54f77cdd9 Mon Sep 17 00:00:00 2001 +From: Aaro Koskinen +Date: Sun, 3 Feb 2019 00:14:33 +0200 +Subject: mmc: omap: fix the maximum timeout setting + +[ Upstream commit a6327b5e57fdc679c842588c3be046c0b39cc127 ] + +When running OMAP1 kernel on QEMU, MMC access is annoyingly noisy: + + MMC: CTO of 0xff and 0xfe cannot be used! + MMC: CTO of 0xff and 0xfe cannot be used! + MMC: CTO of 0xff and 0xfe cannot be used! + [ad inf.] + +Emulator warnings appear to be valid. The TI document SPRU680 [1] +("OMAP5910 Dual-Core Processor MultiMedia Card/Secure Data Memory Card +(MMC/SD) Reference Guide") page 36 states that the maximum timeout is 253 +cycles and "0xff and 0xfe cannot be used". + +Fix by using 0xfd as the maximum timeout. + +Tested using QEMU 2.5 (Siemens SX1 machine, OMAP310), and also checked on +real hardware using Palm TE (OMAP310), Nokia 770 (OMAP1710) and Nokia N810 +(OMAP2420) that MMC works as before. + +[1] http://www.ti.com/lit/ug/spru680/spru680.pdf + +Fixes: 730c9b7e6630f ("[MMC] Add OMAP MMC host driver") +Signed-off-by: Aaro Koskinen +Signed-off-by: Ulf Hansson +Signed-off-by: Sasha Levin +--- + drivers/mmc/host/omap.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/drivers/mmc/host/omap.c b/drivers/mmc/host/omap.c +index 11e5bfedab70..b9f4f39f9359 100644 +--- a/drivers/mmc/host/omap.c ++++ b/drivers/mmc/host/omap.c +@@ -921,7 +921,7 @@ static inline void set_cmd_timeout(struct mmc_omap_host *host, struct mmc_reques + reg &= ~(1 << 5); + OMAP_MMC_WRITE(host, SDIO, reg); + /* Set maximum timeout */ +- OMAP_MMC_WRITE(host, CTO, 0xff); ++ OMAP_MMC_WRITE(host, CTO, 0xfd); + } + + static inline void set_data_timeout(struct mmc_omap_host *host, struct mmc_request *req) +-- +2.19.1 + diff --git a/queue-3.18/ocfs2-fix-a-panic-problem-caused-by-o2cb_ctl.patch b/queue-3.18/ocfs2-fix-a-panic-problem-caused-by-o2cb_ctl.patch new file mode 100644 index 00000000000..be6b0846b18 --- /dev/null +++ b/queue-3.18/ocfs2-fix-a-panic-problem-caused-by-o2cb_ctl.patch @@ -0,0 +1,70 @@ +From f2c45d782fe6b7a85bc41ace11b38e0979dd1bea Mon Sep 17 00:00:00 2001 +From: Jia Guo +Date: Tue, 5 Mar 2019 15:41:41 -0800 +Subject: ocfs2: fix a panic problem caused by o2cb_ctl + +[ Upstream commit cc725ef3cb202ef2019a3c67c8913efa05c3cce6 ] + +In the process of creating a node, it will cause NULL pointer +dereference in kernel if o2cb_ctl failed in the interval (mkdir, +o2cb_set_node_attribute(node_num)] in function o2cb_add_node. + +The node num is initialized to 0 in function o2nm_node_group_make_item, +o2nm_node_group_drop_item will mistake the node number 0 for a valid +node number when we delete the node before the node number is set +correctly. If the local node number of the current host happens to be +0, cluster->cl_local_node will be set to O2NM_INVALID_NODE_NUM while +o2hb_thread still running. The panic stack is generated as follows: + + o2hb_thread + \-o2hb_do_disk_heartbeat + \-o2hb_check_own_slot + |-slot = ®->hr_slots[o2nm_this_node()]; + //o2nm_this_node() return O2NM_INVALID_NODE_NUM + +We need to check whether the node number is set when we delete the node. + +Link: http://lkml.kernel.org/r/133d8045-72cc-863e-8eae-5013f9f6bc51@huawei.com +Signed-off-by: Jia Guo +Reviewed-by: Joseph Qi +Acked-by: Jun Piao +Cc: Mark Fasheh +Cc: Joel Becker +Cc: Junxiao Bi +Cc: Changwei Ge +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Sasha Levin +--- + fs/ocfs2/cluster/nodemanager.c | 14 ++++++++------ + 1 file changed, 8 insertions(+), 6 deletions(-) + +diff --git a/fs/ocfs2/cluster/nodemanager.c b/fs/ocfs2/cluster/nodemanager.c +index 441c84e169e6..059414bb19dc 100644 +--- a/fs/ocfs2/cluster/nodemanager.c ++++ b/fs/ocfs2/cluster/nodemanager.c +@@ -721,13 +721,15 @@ static void o2nm_node_group_drop_item(struct config_group *group, + struct o2nm_node *node = to_o2nm_node(item); + struct o2nm_cluster *cluster = to_o2nm_cluster(group->cg_item.ci_parent); + +- o2net_disconnect_node(node); ++ if (cluster->cl_nodes[node->nd_num] == node) { ++ o2net_disconnect_node(node); + +- if (cluster->cl_has_local && +- (cluster->cl_local_node == node->nd_num)) { +- cluster->cl_has_local = 0; +- cluster->cl_local_node = O2NM_INVALID_NODE_NUM; +- o2net_stop_listening(node); ++ if (cluster->cl_has_local && ++ (cluster->cl_local_node == node->nd_num)) { ++ cluster->cl_has_local = 0; ++ cluster->cl_local_node = O2NM_INVALID_NODE_NUM; ++ o2net_stop_listening(node); ++ } + } + + /* XXX call into net to stop this node from trading messages */ +-- +2.19.1 + diff --git a/queue-3.18/scsi-core-replace-gfp_atomic-with-gfp_kernel-in-scsi.patch b/queue-3.18/scsi-core-replace-gfp_atomic-with-gfp_kernel-in-scsi.patch new file mode 100644 index 00000000000..5510b0c3570 --- /dev/null +++ b/queue-3.18/scsi-core-replace-gfp_atomic-with-gfp_kernel-in-scsi.patch @@ -0,0 +1,114 @@ +From 64468ae98db00e99d8ce68dc45b30b522bb9d073 Mon Sep 17 00:00:00 2001 +From: Benjamin Block +Date: Thu, 21 Feb 2019 10:18:00 +0100 +Subject: scsi: core: replace GFP_ATOMIC with GFP_KERNEL in scsi_scan.c + +[ Upstream commit 1749ef00f7312679f76d5e9104c5d1e22a829038 ] + +We had a test-report where, under memory pressure, adding LUNs to the +systems would fail (the tests add LUNs strictly in sequence): + +[ 5525.853432] scsi 0:0:1:1088045124: Direct-Access IBM 2107900 .148 PQ: 0 ANSI: 5 +[ 5525.853826] scsi 0:0:1:1088045124: alua: supports implicit TPGS +[ 5525.853830] scsi 0:0:1:1088045124: alua: device naa.6005076303ffd32700000000000044da port group 0 rel port 43 +[ 5525.853931] sd 0:0:1:1088045124: Attached scsi generic sg10 type 0 +[ 5525.854075] sd 0:0:1:1088045124: [sdk] Disabling DIF Type 1 protection +[ 5525.855495] sd 0:0:1:1088045124: [sdk] 2097152 512-byte logical blocks: (1.07 GB/1.00 GiB) +[ 5525.855606] sd 0:0:1:1088045124: [sdk] Write Protect is off +[ 5525.855609] sd 0:0:1:1088045124: [sdk] Mode Sense: ed 00 00 08 +[ 5525.855795] sd 0:0:1:1088045124: [sdk] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA +[ 5525.857838] sdk: sdk1 +[ 5525.859468] sd 0:0:1:1088045124: [sdk] Attached SCSI disk +[ 5525.865073] sd 0:0:1:1088045124: alua: transition timeout set to 60 seconds +[ 5525.865078] sd 0:0:1:1088045124: alua: port group 00 state A preferred supports tolusnA +[ 5526.015070] sd 0:0:1:1088045124: alua: port group 00 state A preferred supports tolusnA +[ 5526.015213] sd 0:0:1:1088045124: alua: port group 00 state A preferred supports tolusnA +[ 5526.587439] scsi_alloc_sdev: Allocation failure during SCSI scanning, some SCSI devices might not be configured +[ 5526.588562] scsi_alloc_sdev: Allocation failure during SCSI scanning, some SCSI devices might not be configured + +Looking at the code of scsi_alloc_sdev(), and all the calling contexts, +there seems to be no reason to use GFP_ATMOIC here. All the different +call-contexts use a mutex at some point, and nothing in between that +requires no sleeping, as far as I could see. Additionally, the code that +later allocates the block queue for the device (scsi_mq_alloc_queue()) +already uses GFP_KERNEL. + +There are similar allocations in two other functions: +scsi_probe_and_add_lun(), and scsi_add_lun(),; that can also be done with +GFP_KERNEL. + +Here is the contexts for the three functions so far: + + scsi_alloc_sdev() + scsi_probe_and_add_lun() + scsi_sequential_lun_scan() + __scsi_scan_target() + scsi_scan_target() + mutex_lock() + scsi_scan_channel() + scsi_scan_host_selected() + mutex_lock() + scsi_report_lun_scan() + __scsi_scan_target() + ... + __scsi_add_device() + mutex_lock() + __scsi_scan_target() + ... + scsi_report_lun_scan() + ... + scsi_get_host_dev() + mutex_lock() + + scsi_probe_and_add_lun() + ... + + scsi_add_lun() + scsi_probe_and_add_lun() + ... + +So replace all these, and give them a bit of a better chance to succeed, +with more chances of reclaim. + +Signed-off-by: Benjamin Block +Reviewed-by: Bart Van Assche +Signed-off-by: Martin K. Petersen +Signed-off-by: Sasha Levin +--- + drivers/scsi/scsi_scan.c | 6 +++--- + 1 file changed, 3 insertions(+), 3 deletions(-) + +diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c +index 3386e72ba7e4..156ee22462e6 100644 +--- a/drivers/scsi/scsi_scan.c ++++ b/drivers/scsi/scsi_scan.c +@@ -229,7 +229,7 @@ static struct scsi_device *scsi_alloc_sdev(struct scsi_target *starget, + extern void scsi_requeue_run_queue(struct work_struct *work); + + sdev = kzalloc(sizeof(*sdev) + shost->transportt->device_size, +- GFP_ATOMIC); ++ GFP_KERNEL); + if (!sdev) + goto out; + +@@ -791,7 +791,7 @@ static int scsi_add_lun(struct scsi_device *sdev, unsigned char *inq_result, + */ + sdev->inquiry = kmemdup(inq_result, + max_t(size_t, sdev->inquiry_len, 36), +- GFP_ATOMIC); ++ GFP_KERNEL); + if (sdev->inquiry == NULL) + return SCSI_SCAN_NO_RESPONSE; + +@@ -1083,7 +1083,7 @@ static int scsi_probe_and_add_lun(struct scsi_target *starget, + if (!sdev) + goto out; + +- result = kmalloc(result_len, GFP_ATOMIC | ++ result = kmalloc(result_len, GFP_KERNEL | + ((shost->unchecked_isa_dma) ? __GFP_DMA : 0)); + if (!result) + goto out_free_sdev; +-- +2.19.1 + diff --git a/queue-3.18/scsi-megaraid_sas-return-error-when-create-dma-pool-.patch b/queue-3.18/scsi-megaraid_sas-return-error-when-create-dma-pool-.patch new file mode 100644 index 00000000000..844a90d57e5 --- /dev/null +++ b/queue-3.18/scsi-megaraid_sas-return-error-when-create-dma-pool-.patch @@ -0,0 +1,79 @@ +From aaaf7cf1b7b8402b47fd0314829d4eddab5ea3e4 Mon Sep 17 00:00:00 2001 +From: Jason Yan +Date: Fri, 15 Feb 2019 19:50:27 +0800 +Subject: scsi: megaraid_sas: return error when create DMA pool failed + +[ Upstream commit bcf3b67d16a4c8ffae0aa79de5853435e683945c ] + +when create DMA pool for cmd frames failed, we should return -ENOMEM, +instead of 0. +In some case in: + + megasas_init_adapter_fusion() + + -->megasas_alloc_cmds() + -->megasas_create_frame_pool + create DMA pool failed, + --> megasas_free_cmds() [1] + + -->megasas_alloc_cmds_fusion() + failed, then goto fail_alloc_cmds. + -->megasas_free_cmds() [2] + +we will call megasas_free_cmds twice, [1] will kfree cmd_list, +[2] will use cmd_list.it will cause a problem: + +Unable to handle kernel NULL pointer dereference at virtual address +00000000 +pgd = ffffffc000f70000 +[00000000] *pgd=0000001fbf893003, *pud=0000001fbf893003, +*pmd=0000001fbf894003, *pte=006000006d000707 +Internal error: Oops: 96000005 [#1] SMP + Modules linked in: + CPU: 18 PID: 1 Comm: swapper/0 Not tainted + task: ffffffdfb9290000 ti: ffffffdfb923c000 task.ti: ffffffdfb923c000 + PC is at megasas_free_cmds+0x30/0x70 + LR is at megasas_free_cmds+0x24/0x70 + ... + Call trace: + [] megasas_free_cmds+0x30/0x70 + [] megasas_init_adapter_fusion+0x2f4/0x4d8 + [] megasas_init_fw+0x2dc/0x760 + [] megasas_probe_one+0x3c0/0xcd8 + [] local_pci_probe+0x4c/0xb4 + [] pci_device_probe+0x11c/0x14c + [] driver_probe_device+0x1ec/0x430 + [] __driver_attach+0xa8/0xb0 + [] bus_for_each_dev+0x74/0xc8 + [] driver_attach+0x28/0x34 + [] bus_add_driver+0x16c/0x248 + [] driver_register+0x6c/0x138 + [] __pci_register_driver+0x5c/0x6c + [] megasas_init+0xc0/0x1a8 + [] do_one_initcall+0xe8/0x1ec + [] kernel_init_freeable+0x1c8/0x284 + [] kernel_init+0x1c/0xe4 + +Signed-off-by: Jason Yan +Acked-by: Sumit Saxena +Signed-off-by: Martin K. Petersen +Signed-off-by: Sasha Levin +--- + drivers/scsi/megaraid/megaraid_sas_base.c | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c b/drivers/scsi/megaraid/megaraid_sas_base.c +index 1ff0ece87644..24cc8786ff06 100644 +--- a/drivers/scsi/megaraid/megaraid_sas_base.c ++++ b/drivers/scsi/megaraid/megaraid_sas_base.c +@@ -3743,6 +3743,7 @@ int megasas_alloc_cmds(struct megasas_instance *instance) + if (megasas_create_frame_pool(instance)) { + printk(KERN_DEBUG "megasas: Error creating frame DMA pool\n"); + megasas_free_cmds(instance); ++ return -ENOMEM; + } + + return 0; +-- +2.19.1 + diff --git a/queue-3.18/series b/queue-3.18/series index 049e9b1a4d7..0958b792ed5 100644 --- a/queue-3.18/series +++ b/queue-3.18/series @@ -1,2 +1,41 @@ ext4-cleanup-bh-release-code-in-ext4_ind_remove_space.patch i2c-core-smbus-prevent-stack-corruption-on-read-i2c_block_data.patch +tracing-kdb-fix-ftdump-to-not-sleep.patch +sysctl-handle-overflow-for-file-max.patch +mm-cma.c-cma_declare_contiguous-correct-err-handling.patch +mm-vmalloc.c-fix-kernel-bug-at-mm-vmalloc.c-512.patch +mm-slab.c-kmemleak-no-scan-alien-caches.patch +ocfs2-fix-a-panic-problem-caused-by-o2cb_ctl.patch +cifs-use-correct-format-characters.patch +dm-thin-add-sanity-checks-to-thin-pool-and-external-.patch +cifs-fix-null-pointer-dereference-of-devname.patch +fs-fix-guard_bio_eod-to-check-for-real-eod-errors.patch +tools-lib-traceevent-fix-buffer-overflow-in-arg_eval.patch +scsi-core-replace-gfp_atomic-with-gfp_kernel-in-scsi.patch +arm-8840-1-use-a-raw_spinlock_t-in-unwind.patch +mmc-omap-fix-the-maximum-timeout-setting.patch +e1000e-fix-wformat-truncation-warnings.patch +ib-mlx4-increase-the-timeout-for-cm-cache.patch +scsi-megaraid_sas-return-error-when-create-dma-pool-.patch +soc-imx-sgtl5000-add-missing-put_device.patch +leds-lp55xx-fix-null-deref-on-firmware-load-failure.patch +kprobes-prohibit-probing-on-bsearch.patch +arm-8833-1-ensure-that-neon-code-always-compiles-wit.patch +alsa-pcm-check-if-ops-are-defined-before-suspending-.patch +bcache-fix-input-overflow-to-cache-set-sysfs-file-io.patch +bcache-fix-input-overflow-to-sequential_cutoff.patch +bcache-improve-sysfs_strtoul_clamp.patch +fbdev-fbmem-fix-memory-access-if-logo-is-bigger-than.patch +cdrom-fix-race-condition-in-cdrom_sysctl_register.patch +e1000e-fix-cyclic-resets-at-link-up-with-active-tx.patch +locking-lockdep-add-debug_locks-check-in-__lock_down.patch +tty-increase-the-default-flip-buffer-limit-to-2-640k.patch +media-mt9m111-set-initial-frame-size-other-than-0x0.patch +hwrng-virtio-avoid-repeated-init-of-completion.patch +hpet-fix-missing-character-in-the-__setup-code-of-hp.patch +dmaengine-imx-dma-fix-warning-comparison-of-distinct.patch +media-s5p-jpeg-check-for-fmt_ver_flag-when-doing-fmt.patch +wlcore-fix-memory-leak-in-case-wl12xx_fetch_firmware.patch +x86-build-mark-per-cpu-symbols-as-absolute-explicitl.patch +dmaengine-tegra-avoid-overflow-of-byte-tracking.patch +drm-dp-mst-configure-no_stop_bit-correctly-for-remot.patch diff --git a/queue-3.18/soc-imx-sgtl5000-add-missing-put_device.patch b/queue-3.18/soc-imx-sgtl5000-add-missing-put_device.patch new file mode 100644 index 00000000000..46f1c69aa3e --- /dev/null +++ b/queue-3.18/soc-imx-sgtl5000-add-missing-put_device.patch @@ -0,0 +1,56 @@ +From 533192aee1c2018175b2e0d4062d8dac91d75299 Mon Sep 17 00:00:00 2001 +From: Wen Yang +Date: Mon, 18 Feb 2019 15:13:47 +0000 +Subject: SoC: imx-sgtl5000: add missing put_device() + +[ Upstream commit 8fa857da9744f513036df1c43ab57f338941ae7d ] + +The of_find_device_by_node() takes a reference to the underlying device +structure, we should release that reference. + +Detected by coccinelle with the following warnings: +./sound/soc/fsl/imx-sgtl5000.c:169:1-7: ERROR: missing put_device; +call of_find_device_by_node on line 105, but without a corresponding +object release within this function. +./sound/soc/fsl/imx-sgtl5000.c:177:1-7: ERROR: missing put_device; +call of_find_device_by_node on line 105, but without a corresponding +object release within this function. + +Signed-off-by: Wen Yang +Cc: Timur Tabi +Cc: Nicolin Chen +Cc: Xiubo Li +Cc: Fabio Estevam +Cc: Liam Girdwood +Cc: Mark Brown +Cc: Jaroslav Kysela +Cc: Takashi Iwai +Cc: Shawn Guo +Cc: Sascha Hauer +Cc: Pengutronix Kernel Team +Cc: NXP Linux Team +Cc: alsa-devel@alsa-project.org +Cc: linuxppc-dev@lists.ozlabs.org +Cc: linux-arm-kernel@lists.infradead.org +Cc: linux-kernel@vger.kernel.org +Signed-off-by: Mark Brown +Signed-off-by: Sasha Levin +--- + sound/soc/fsl/imx-sgtl5000.c | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/sound/soc/fsl/imx-sgtl5000.c b/sound/soc/fsl/imx-sgtl5000.c +index 1cb22dd034eb..110f3cf361af 100644 +--- a/sound/soc/fsl/imx-sgtl5000.c ++++ b/sound/soc/fsl/imx-sgtl5000.c +@@ -115,6 +115,7 @@ static int imx_sgtl5000_probe(struct platform_device *pdev) + ret = -EPROBE_DEFER; + goto fail; + } ++ put_device(&ssi_pdev->dev); + codec_dev = of_find_i2c_device_by_node(codec_np); + if (!codec_dev) { + dev_err(&pdev->dev, "failed to find codec platform device\n"); +-- +2.19.1 + diff --git a/queue-3.18/sysctl-handle-overflow-for-file-max.patch b/queue-3.18/sysctl-handle-overflow-for-file-max.patch new file mode 100644 index 00000000000..7c56c9c7767 --- /dev/null +++ b/queue-3.18/sysctl-handle-overflow-for-file-max.patch @@ -0,0 +1,70 @@ +From 886a87a7e354b77985cde72a5af70665faa888d3 Mon Sep 17 00:00:00 2001 +From: Christian Brauner +Date: Thu, 7 Mar 2019 16:29:43 -0800 +Subject: sysctl: handle overflow for file-max + +[ Upstream commit 32a5ad9c22852e6bd9e74bdec5934ef9d1480bc5 ] + +Currently, when writing + + echo 18446744073709551616 > /proc/sys/fs/file-max + +/proc/sys/fs/file-max will overflow and be set to 0. That quickly +crashes the system. + +This commit sets the max and min value for file-max. The max value is +set to long int. Any higher value cannot currently be used as the +percpu counters are long ints and not unsigned integers. + +Note that the file-max value is ultimately parsed via +__do_proc_doulongvec_minmax(). This function does not report error when +min or max are exceeded. Which means if a value largen that long int is +written userspace will not receive an error instead the old value will be +kept. There is an argument to be made that this should be changed and +__do_proc_doulongvec_minmax() should return an error when a dedicated min +or max value are exceeded. However this has the potential to break +userspace so let's defer this to an RFC patch. + +Link: http://lkml.kernel.org/r/20190107222700.15954-3-christian@brauner.io +Signed-off-by: Christian Brauner +Acked-by: Kees Cook +Cc: Alexey Dobriyan +Cc: Al Viro +Cc: Dominik Brodowski +Cc: "Eric W. Biederman" +Cc: Joe Lawrence +Cc: Luis Chamberlain +Cc: Waiman Long +[christian@brauner.io: v4] + Link: http://lkml.kernel.org/r/20190210203943.8227-3-christian@brauner.io +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Sasha Levin +--- + kernel/sysctl.c | 3 +++ + 1 file changed, 3 insertions(+) + +diff --git a/kernel/sysctl.c b/kernel/sysctl.c +index 27f8aa765493..a68fed9f6922 100644 +--- a/kernel/sysctl.c ++++ b/kernel/sysctl.c +@@ -125,6 +125,7 @@ static int __maybe_unused one = 1; + static int __maybe_unused two = 2; + static int __maybe_unused four = 4; + static unsigned long one_ul = 1; ++static unsigned long long_max = LONG_MAX; + static int one_hundred = 100; + #ifdef CONFIG_PRINTK + static int ten_thousand = 10000; +@@ -1521,6 +1522,8 @@ static struct ctl_table fs_table[] = { + .maxlen = sizeof(files_stat.max_files), + .mode = 0644, + .proc_handler = proc_doulongvec_minmax, ++ .extra1 = &zero, ++ .extra2 = &long_max, + }, + { + .procname = "nr_open", +-- +2.19.1 + diff --git a/queue-3.18/tools-lib-traceevent-fix-buffer-overflow-in-arg_eval.patch b/queue-3.18/tools-lib-traceevent-fix-buffer-overflow-in-arg_eval.patch new file mode 100644 index 00000000000..62fffe5e196 --- /dev/null +++ b/queue-3.18/tools-lib-traceevent-fix-buffer-overflow-in-arg_eval.patch @@ -0,0 +1,47 @@ +From b97cd8d67ac35c95d6427622b73aeb0756ccaf9c Mon Sep 17 00:00:00 2001 +From: Tony Jones +Date: Wed, 27 Feb 2019 17:55:32 -0800 +Subject: tools lib traceevent: Fix buffer overflow in arg_eval + +[ Upstream commit 7c5b019e3a638a5a290b0ec020f6ca83d2ec2aaa ] + +Fix buffer overflow observed when running perf test. + +The overflow is when trying to evaluate "1ULL << (64 - 1)" which is +resulting in -9223372036854775808 which overflows the 20 character +buffer. + +If is possible this bug has been reported before but I still don't see +any fix checked in: + +See: https://www.spinics.net/lists/linux-perf-users/msg07714.html + +Reported-by: Michael Sartain +Reported-by: Mathias Krause +Signed-off-by: Tony Jones +Acked-by: Steven Rostedt (VMware) +Cc: Frederic Weisbecker +Fixes: f7d82350e597 ("tools/events: Add files to create libtraceevent.a") +Link: http://lkml.kernel.org/r/20190228015532.8941-1-tonyj@suse.de +Signed-off-by: Arnaldo Carvalho de Melo +Signed-off-by: Sasha Levin +--- + tools/lib/traceevent/event-parse.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/tools/lib/traceevent/event-parse.c b/tools/lib/traceevent/event-parse.c +index 0c81ca7d18cd..84374e313e3f 100644 +--- a/tools/lib/traceevent/event-parse.c ++++ b/tools/lib/traceevent/event-parse.c +@@ -2283,7 +2283,7 @@ static int arg_num_eval(struct print_arg *arg, long long *val) + static char *arg_eval (struct print_arg *arg) + { + long long val; +- static char buf[20]; ++ static char buf[24]; + + switch (arg->type) { + case PRINT_ATOM: +-- +2.19.1 + diff --git a/queue-3.18/tracing-kdb-fix-ftdump-to-not-sleep.patch b/queue-3.18/tracing-kdb-fix-ftdump-to-not-sleep.patch new file mode 100644 index 00000000000..e9d56229b08 --- /dev/null +++ b/queue-3.18/tracing-kdb-fix-ftdump-to-not-sleep.patch @@ -0,0 +1,143 @@ +From c3ac9901ad59d59f74ddfe7f26be00daa7a1ebec Mon Sep 17 00:00:00 2001 +From: Douglas Anderson +Date: Fri, 8 Mar 2019 11:32:04 -0800 +Subject: tracing: kdb: Fix ftdump to not sleep + +[ Upstream commit 31b265b3baaf55f209229888b7ffea523ddab366 ] + +As reported back in 2016-11 [1], the "ftdump" kdb command triggers a +BUG for "sleeping function called from invalid context". + +kdb's "ftdump" command wants to call ring_buffer_read_prepare() in +atomic context. A very simple solution for this is to add allocation +flags to ring_buffer_read_prepare() so kdb can call it without +triggering the allocation error. This patch does that. + +Note that in the original email thread about this, it was suggested +that perhaps the solution for kdb was to either preallocate the buffer +ahead of time or create our own iterator. I'm hoping that this +alternative of adding allocation flags to ring_buffer_read_prepare() +can be considered since it means I don't need to duplicate more of the +core trace code into "trace_kdb.c" (for either creating my own +iterator or re-preparing a ring allocator whose memory was already +allocated). + +NOTE: another option for kdb is to actually figure out how to make it +reuse the existing ftrace_dump() function and totally eliminate the +duplication. This sounds very appealing and actually works (the "sr +z" command can be seen to properly dump the ftrace buffer). The +downside here is that ftrace_dump() fully consumes the trace buffer. +Unless that is changed I'd rather not use it because it means "ftdump +| grep xyz" won't be very useful to search the ftrace buffer since it +will throw away the whole trace on the first grep. A future patch to +dump only the last few lines of the buffer will also be hard to +implement. + +[1] https://lkml.kernel.org/r/20161117191605.GA21459@google.com + +Link: http://lkml.kernel.org/r/20190308193205.213659-1-dianders@chromium.org + +Reported-by: Brian Norris +Signed-off-by: Douglas Anderson +Signed-off-by: Steven Rostedt (VMware) +Signed-off-by: Sasha Levin +--- + include/linux/ring_buffer.h | 2 +- + kernel/trace/ring_buffer.c | 5 +++-- + kernel/trace/trace.c | 6 ++++-- + kernel/trace/trace_kdb.c | 6 ++++-- + 4 files changed, 12 insertions(+), 7 deletions(-) + +diff --git a/include/linux/ring_buffer.h b/include/linux/ring_buffer.h +index 4daa5069cbdb..561f79803c13 100644 +--- a/include/linux/ring_buffer.h ++++ b/include/linux/ring_buffer.h +@@ -125,7 +125,7 @@ ring_buffer_consume(struct ring_buffer *buffer, int cpu, u64 *ts, + unsigned long *lost_events); + + struct ring_buffer_iter * +-ring_buffer_read_prepare(struct ring_buffer *buffer, int cpu); ++ring_buffer_read_prepare(struct ring_buffer *buffer, int cpu, gfp_t flags); + void ring_buffer_read_prepare_sync(void); + void ring_buffer_read_start(struct ring_buffer_iter *iter); + void ring_buffer_read_finish(struct ring_buffer_iter *iter); +diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c +index d2b609412c3a..173ff025ea75 100644 +--- a/kernel/trace/ring_buffer.c ++++ b/kernel/trace/ring_buffer.c +@@ -4039,6 +4039,7 @@ EXPORT_SYMBOL_GPL(ring_buffer_consume); + * ring_buffer_read_prepare - Prepare for a non consuming read of the buffer + * @buffer: The ring buffer to read from + * @cpu: The cpu buffer to iterate over ++ * @flags: gfp flags to use for memory allocation + * + * This performs the initial preparations necessary to iterate + * through the buffer. Memory is allocated, buffer recording +@@ -4056,7 +4057,7 @@ EXPORT_SYMBOL_GPL(ring_buffer_consume); + * This overall must be paired with ring_buffer_read_finish. + */ + struct ring_buffer_iter * +-ring_buffer_read_prepare(struct ring_buffer *buffer, int cpu) ++ring_buffer_read_prepare(struct ring_buffer *buffer, int cpu, gfp_t flags) + { + struct ring_buffer_per_cpu *cpu_buffer; + struct ring_buffer_iter *iter; +@@ -4064,7 +4065,7 @@ ring_buffer_read_prepare(struct ring_buffer *buffer, int cpu) + if (!cpumask_test_cpu(cpu, buffer->cpumask)) + return NULL; + +- iter = kmalloc(sizeof(*iter), GFP_KERNEL); ++ iter = kmalloc(sizeof(*iter), flags); + if (!iter) + return NULL; + +diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c +index 69af9a1b1031..934c1a1813dd 100644 +--- a/kernel/trace/trace.c ++++ b/kernel/trace/trace.c +@@ -3047,7 +3047,8 @@ __tracing_open(struct inode *inode, struct file *file, bool snapshot) + if (iter->cpu_file == RING_BUFFER_ALL_CPUS) { + for_each_tracing_cpu(cpu) { + iter->buffer_iter[cpu] = +- ring_buffer_read_prepare(iter->trace_buffer->buffer, cpu); ++ ring_buffer_read_prepare(iter->trace_buffer->buffer, ++ cpu, GFP_KERNEL); + } + ring_buffer_read_prepare_sync(); + for_each_tracing_cpu(cpu) { +@@ -3057,7 +3058,8 @@ __tracing_open(struct inode *inode, struct file *file, bool snapshot) + } else { + cpu = iter->cpu_file; + iter->buffer_iter[cpu] = +- ring_buffer_read_prepare(iter->trace_buffer->buffer, cpu); ++ ring_buffer_read_prepare(iter->trace_buffer->buffer, ++ cpu, GFP_KERNEL); + ring_buffer_read_prepare_sync(); + ring_buffer_read_start(iter->buffer_iter[cpu]); + tracing_iter_reset(iter, cpu); +diff --git a/kernel/trace/trace_kdb.c b/kernel/trace/trace_kdb.c +index bd90e1b06088..ebbf28492573 100644 +--- a/kernel/trace/trace_kdb.c ++++ b/kernel/trace/trace_kdb.c +@@ -46,14 +46,16 @@ static void ftrace_dump_buf(int skip_lines, long cpu_file) + if (cpu_file == RING_BUFFER_ALL_CPUS) { + for_each_tracing_cpu(cpu) { + iter.buffer_iter[cpu] = +- ring_buffer_read_prepare(iter.trace_buffer->buffer, cpu); ++ ring_buffer_read_prepare(iter.trace_buffer->buffer, ++ cpu, GFP_ATOMIC); + ring_buffer_read_start(iter.buffer_iter[cpu]); + tracing_iter_reset(&iter, cpu); + } + } else { + iter.cpu_file = cpu_file; + iter.buffer_iter[cpu_file] = +- ring_buffer_read_prepare(iter.trace_buffer->buffer, cpu_file); ++ ring_buffer_read_prepare(iter.trace_buffer->buffer, ++ cpu_file, GFP_ATOMIC); + ring_buffer_read_start(iter.buffer_iter[cpu_file]); + tracing_iter_reset(&iter, cpu_file); + } +-- +2.19.1 + diff --git a/queue-3.18/tty-increase-the-default-flip-buffer-limit-to-2-640k.patch b/queue-3.18/tty-increase-the-default-flip-buffer-limit-to-2-640k.patch new file mode 100644 index 00000000000..a804de1ed11 --- /dev/null +++ b/queue-3.18/tty-increase-the-default-flip-buffer-limit-to-2-640k.patch @@ -0,0 +1,51 @@ +From 5cb289f6835858af2028b4e0ad1c50f20be350d9 Mon Sep 17 00:00:00 2001 +From: Manfred Schlaegl +Date: Mon, 28 Jan 2019 19:01:10 +0100 +Subject: tty: increase the default flip buffer limit to 2*640K + +[ Upstream commit 7ab57b76ebf632bf2231ccabe26bea33868118c6 ] + +We increase the default limit for buffer memory allocation by a factor of +10 to 640K to prevent data loss when using fast serial interfaces. + +For example when using RS485 without flow-control at speeds of 1Mbit/s +an upwards we've run into problems such as applications being too slow +to read out this buffer (on embedded devices based on imx53 or imx6). + +If you want to write transmitted data to a slow SD card and thus have +realtime requirements, this limit can become a problem. + +That shouldn't be the case and 640K buffers fix such problems for us. + +This value is a maximum limit for allocation only. It has no effect +on systems that currently run fine. When transmission is slow enough +applications and hardware can keep up and increasing this limit +doesn't change anything. + +It only _allows_ to allocate more than 2*64K in cases we currently fail to +allocate memory despite having some. + +Signed-off-by: Manfred Schlaegl +Signed-off-by: Martin Kepplinger +Signed-off-by: Greg Kroah-Hartman +Signed-off-by: Sasha Levin +--- + drivers/tty/tty_buffer.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/drivers/tty/tty_buffer.c b/drivers/tty/tty_buffer.c +index 0d3fc2dae23a..50616c949e8e 100644 +--- a/drivers/tty/tty_buffer.c ++++ b/drivers/tty/tty_buffer.c +@@ -25,7 +25,7 @@ + * Byte threshold to limit memory consumption for flip buffers. + * The actual memory limit is > 2x this amount. + */ +-#define TTYB_DEFAULT_MEM_LIMIT 65536 ++#define TTYB_DEFAULT_MEM_LIMIT (640 * 1024UL) + + /* + * We default to dicing tty buffer allocations to this many characters +-- +2.19.1 + diff --git a/queue-3.18/wlcore-fix-memory-leak-in-case-wl12xx_fetch_firmware.patch b/queue-3.18/wlcore-fix-memory-leak-in-case-wl12xx_fetch_firmware.patch new file mode 100644 index 00000000000..bd9ead7ad57 --- /dev/null +++ b/queue-3.18/wlcore-fix-memory-leak-in-case-wl12xx_fetch_firmware.patch @@ -0,0 +1,59 @@ +From 7f8be1b441b2e1076dc50e279815825294452f86 Mon Sep 17 00:00:00 2001 +From: Zumeng Chen +Date: Wed, 19 Dec 2018 15:50:29 +0800 +Subject: wlcore: Fix memory leak in case wl12xx_fetch_firmware failure + +[ Upstream commit ba2ffc96321c8433606ceeb85c9e722b8113e5a7 ] + +Release fw_status, raw_fw_status, and tx_res_if when wl12xx_fetch_firmware +failed instead of meaningless goto out to avoid the following memory leak +reports(Only the last one listed): + +unreferenced object 0xc28a9a00 (size 512): + comm "kworker/0:4", pid 31298, jiffies 2783204 (age 203.290s) + hex dump (first 32 bytes): + 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ + 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ + backtrace: + [<6624adab>] kmemleak_alloc+0x40/0x74 + [<500ddb31>] kmem_cache_alloc_trace+0x1ac/0x270 + [] wl12xx_chip_wakeup+0xc4/0x1fc [wlcore] + [<76c5db53>] wl1271_op_add_interface+0x4a4/0x8f4 [wlcore] + [] drv_add_interface+0xa4/0x1a0 [mac80211] + [<65bac325>] ieee80211_reconfig+0x9c0/0x1644 [mac80211] + [<2817c80e>] ieee80211_restart_work+0x90/0xc8 [mac80211] + [<7e1d425a>] process_one_work+0x284/0x42c + [<55f9432e>] worker_thread+0x2fc/0x48c + [] kthread+0x148/0x160 + [<63144b13>] ret_from_fork+0x14/0x2c + [< (null)>] (null) + [<1f6e7715>] 0xffffffff + +Signed-off-by: Zumeng Chen +Signed-off-by: Kalle Valo +Signed-off-by: Sasha Levin +--- + drivers/net/wireless/ti/wlcore/main.c | 7 +++++-- + 1 file changed, 5 insertions(+), 2 deletions(-) + +diff --git a/drivers/net/wireless/ti/wlcore/main.c b/drivers/net/wireless/ti/wlcore/main.c +index 575c8f6d4009..16b69b026f8f 100644 +--- a/drivers/net/wireless/ti/wlcore/main.c ++++ b/drivers/net/wireless/ti/wlcore/main.c +@@ -1110,8 +1110,11 @@ static int wl12xx_chip_wakeup(struct wl1271 *wl, bool plt) + goto out; + + ret = wl12xx_fetch_firmware(wl, plt); +- if (ret < 0) +- goto out; ++ if (ret < 0) { ++ kfree(wl->fw_status); ++ kfree(wl->raw_fw_status); ++ kfree(wl->tx_res_if); ++ } + + out: + return ret; +-- +2.19.1 + diff --git a/queue-3.18/x86-build-mark-per-cpu-symbols-as-absolute-explicitl.patch b/queue-3.18/x86-build-mark-per-cpu-symbols-as-absolute-explicitl.patch new file mode 100644 index 00000000000..601b6b88017 --- /dev/null +++ b/queue-3.18/x86-build-mark-per-cpu-symbols-as-absolute-explicitl.patch @@ -0,0 +1,80 @@ +From 7baf64c75458df5078a9a0ada893f009c328b6ed Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Rafael=20=C3=81vila=20de=20Esp=C3=ADndola?= + +Date: Wed, 19 Dec 2018 11:01:43 -0800 +Subject: x86/build: Mark per-CPU symbols as absolute explicitly for LLD +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +[ Upstream commit d071ae09a4a1414c1433d5ae9908959a7325b0ad ] + +Accessing per-CPU variables is done by finding the offset of the +variable in the per-CPU block and adding it to the address of the +respective CPU's block. + +Section 3.10.8 of ld.bfd's documentation states: + + For expressions involving numbers, relative addresses and absolute + addresses, ld follows these rules to evaluate terms: + + Other binary operations, that is, between two relative addresses + not in the same section, or between a relative address and an + absolute address, first convert any non-absolute term to an + absolute address before applying the operator." + +Note that LLVM's linker does not adhere to the GNU ld's implementation +and as such requires implicitly-absolute terms to be explicitly marked +as absolute in the linker script. If not, it fails currently with: + + ld.lld: error: ./arch/x86/kernel/vmlinux.lds:153: at least one side of the expression must be absolute + ld.lld: error: ./arch/x86/kernel/vmlinux.lds:154: at least one side of the expression must be absolute + Makefile:1040: recipe for target 'vmlinux' failed + +This is not a functional change for ld.bfd which converts the term to an +absolute symbol anyways as specified above. + +Based on a previous submission by Tri Vo . + +Reported-by: Dmitry Golovin +Signed-off-by: Rafael Ávila de Espíndola +[ Update commit message per Boris' and Michael's suggestions. ] +Signed-off-by: Nick Desaulniers +[ Massage commit message more, fix typos. ] +Signed-off-by: Borislav Petkov +Tested-by: Dmitry Golovin +Cc: "H. Peter Anvin" +Cc: Andy Lutomirski +Cc: Brijesh Singh +Cc: Cao Jin +Cc: Ingo Molnar +Cc: Joerg Roedel +Cc: Masahiro Yamada +Cc: Masami Hiramatsu +Cc: Thomas Gleixner +Cc: Tri Vo +Cc: dima@golovin.in +Cc: morbo@google.com +Cc: x86-ml +Link: https://lkml.kernel.org/r/20181219190145.252035-1-ndesaulniers@google.com +Signed-off-by: Sasha Levin +--- + arch/x86/kernel/vmlinux.lds.S | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/arch/x86/kernel/vmlinux.lds.S b/arch/x86/kernel/vmlinux.lds.S +index 49edf2dd3613..1bd47a144db1 100644 +--- a/arch/x86/kernel/vmlinux.lds.S ++++ b/arch/x86/kernel/vmlinux.lds.S +@@ -345,7 +345,7 @@ SECTIONS + * Per-cpu symbols which need to be offset from __per_cpu_load + * for the boot processor. + */ +-#define INIT_PER_CPU(x) init_per_cpu__##x = x + __per_cpu_load ++#define INIT_PER_CPU(x) init_per_cpu__##x = ABSOLUTE(x) + __per_cpu_load + INIT_PER_CPU(gdt_page); + INIT_PER_CPU(irq_stack_union); + +-- +2.19.1 +