--- /dev/null
+From 7b0eb6b41a08fa1fa0d04b1c53becd62b5fbfaee Mon Sep 17 00:00:00 2001
+From: Johannes Weiner <hannes@cmpxchg.org>
+Date: Mon, 23 Jul 2018 10:18:23 -0400
+Subject: arm64: fix vmemmap BUILD_BUG_ON() triggering on !vmemmap setups
+
+From: Johannes Weiner <hannes@cmpxchg.org>
+
+commit 7b0eb6b41a08fa1fa0d04b1c53becd62b5fbfaee upstream.
+
+Arnd reports the following arm64 randconfig build error with the PSI
+patches that add another page flag:
+
+ /git/arm-soc/arch/arm64/mm/init.c: In function 'mem_init':
+ /git/arm-soc/include/linux/compiler.h:357:38: error: call to
+ '__compiletime_assert_618' declared with attribute error: BUILD_BUG_ON
+ failed: sizeof(struct page) > (1 << STRUCT_PAGE_MAX_SHIFT)
+
+The additional page flag causes other information stored in
+page->flags to get bumped into their own struct page member:
+
+ #if SECTIONS_WIDTH+ZONES_WIDTH+NODES_SHIFT+LAST_CPUPID_SHIFT <=
+ BITS_PER_LONG - NR_PAGEFLAGS
+ #define LAST_CPUPID_WIDTH LAST_CPUPID_SHIFT
+ #else
+ #define LAST_CPUPID_WIDTH 0
+ #endif
+
+ #if defined(CONFIG_NUMA_BALANCING) && LAST_CPUPID_WIDTH == 0
+ #define LAST_CPUPID_NOT_IN_PAGE_FLAGS
+ #endif
+
+which in turn causes the struct page size to exceed the size set in
+STRUCT_PAGE_MAX_SHIFT. This value is an an estimate used to size the
+VMEMMAP page array according to address space and struct page size.
+
+However, the check is performed - and triggers here - on a !VMEMMAP
+config, which consumes an additional 22 page bits for the sparse
+section id. When VMEMMAP is enabled, those bits are returned, cpupid
+doesn't need its own member, and the page passes the VMEMMAP check.
+
+Restrict that check to the situation it was meant to check: that we
+are sizing the VMEMMAP page array correctly.
+
+Says Arnd:
+
+ Further experiments show that the build error already existed before,
+ but was only triggered with larger values of CONFIG_NR_CPU and/or
+ CONFIG_NODES_SHIFT that might be used in actual configurations but
+ not in randconfig builds.
+
+ With longer CPU and node masks, I could recreate the problem with
+ kernels as old as linux-4.7 when arm64 NUMA support got added.
+
+Reported-by: Arnd Bergmann <arnd@arndb.de>
+Tested-by: Arnd Bergmann <arnd@arndb.de>
+Cc: stable@vger.kernel.org
+Fixes: 1a2db300348b ("arm64, numa: Add NUMA support for arm64 platforms.")
+Fixes: 3e1907d5bf5a ("arm64: mm: move vmemmap region right below the linear region")
+Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
+Signed-off-by: Will Deacon <will.deacon@arm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/arm64/mm/init.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/arch/arm64/mm/init.c
++++ b/arch/arm64/mm/init.c
+@@ -468,11 +468,13 @@ void __init mem_init(void)
+ BUILD_BUG_ON(TASK_SIZE_32 > TASK_SIZE_64);
+ #endif
+
++#ifdef CONFIG_SPARSEMEM_VMEMMAP
+ /*
+ * Make sure we chose the upper bound of sizeof(struct page)
+- * correctly.
++ * correctly when sizing the VMEMMAP array.
+ */
+ BUILD_BUG_ON(sizeof(struct page) > (1 << STRUCT_PAGE_MAX_SHIFT));
++#endif
+
+ if (PAGE_SIZE >= 16384 && get_num_physpages() <= 128) {
+ extern int sysctl_overcommit_memory;
--- /dev/null
+From 938f45008d8bc391593c97508bc798cc95a52b9b Mon Sep 17 00:00:00 2001
+From: Donald Shanty III <dshanty@protonmail.com>
+Date: Wed, 4 Jul 2018 15:50:47 +0000
+Subject: Input: elan_i2c - add ACPI ID for lenovo ideapad 330
+
+From: Donald Shanty III <dshanty@protonmail.com>
+
+commit 938f45008d8bc391593c97508bc798cc95a52b9b upstream.
+
+This allows Elan driver to bind to the touchpad found in Lenovo Ideapad 330
+series laptops.
+
+Signed-off-by: Donald Shanty III <dshanty@protonmail.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/input/mouse/elan_i2c_core.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/input/mouse/elan_i2c_core.c
++++ b/drivers/input/mouse/elan_i2c_core.c
+@@ -1251,6 +1251,7 @@ static const struct acpi_device_id elan_
+ { "ELAN0611", 0 },
+ { "ELAN0612", 0 },
+ { "ELAN0618", 0 },
++ { "ELAN061D", 0 },
+ { "ELAN1000", 0 },
+ { }
+ };
--- /dev/null
+From 6f88a6439da5d94de334a341503bc2c7f4a7ea7f Mon Sep 17 00:00:00 2001
+From: KT Liao <kt.liao@emc.com.tw>
+Date: Mon, 16 Jul 2018 12:10:03 +0000
+Subject: Input: elan_i2c - add another ACPI ID for Lenovo Ideapad 330-15AST
+
+From: KT Liao <kt.liao@emc.com.tw>
+
+commit 6f88a6439da5d94de334a341503bc2c7f4a7ea7f upstream.
+
+Add ELAN0622 to ACPI mapping table to support Elan touchpad found in
+Ideapad 330-15AST.
+
+Signed-off-by: KT Liao <kt.liao@emc.com.tw>
+Reported-by: Anant Shende <anantshende@gmail.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/input/mouse/elan_i2c_core.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/input/mouse/elan_i2c_core.c
++++ b/drivers/input/mouse/elan_i2c_core.c
+@@ -1252,6 +1252,7 @@ static const struct acpi_device_id elan_
+ { "ELAN0612", 0 },
+ { "ELAN0618", 0 },
+ { "ELAN061D", 0 },
++ { "ELAN0622", 0 },
+ { "ELAN1000", 0 },
+ { }
+ };
--- /dev/null
+From 384cf4285b34e08917e3e66603382f2b0c4f6e1b Mon Sep 17 00:00:00 2001
+From: Chen-Yu Tsai <wens@csie.org>
+Date: Wed, 18 Jul 2018 17:24:35 +0000
+Subject: Input: i8042 - add Lenovo LaVie Z to the i8042 reset list
+
+From: Chen-Yu Tsai <wens@csie.org>
+
+commit 384cf4285b34e08917e3e66603382f2b0c4f6e1b upstream.
+
+The Lenovo LaVie Z laptop requires i8042 to be reset in order to
+consistently detect its Elantech touchpad. The nomux and kbdreset
+quirks are not sufficient.
+
+It's possible the other LaVie Z models from NEC require this as well.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Chen-Yu Tsai <wens@csie.org>
+Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/input/serio/i8042-x86ia64io.h | 7 +++++++
+ 1 file changed, 7 insertions(+)
+
+--- a/drivers/input/serio/i8042-x86ia64io.h
++++ b/drivers/input/serio/i8042-x86ia64io.h
+@@ -527,6 +527,13 @@ static const struct dmi_system_id __init
+ DMI_MATCH(DMI_PRODUCT_NAME, "N24_25BU"),
+ },
+ },
++ {
++ /* Lenovo LaVie Z */
++ .matches = {
++ DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
++ DMI_MATCH(DMI_PRODUCT_VERSION, "Lenovo LaVie Z"),
++ },
++ },
+ { }
+ };
+
--- /dev/null
+From 3e536e222f2930534c252c1cc7ae799c725c5ff9 Mon Sep 17 00:00:00 2001
+From: Snild Dolkow <snild@sony.com>
+Date: Thu, 26 Jul 2018 09:15:39 +0200
+Subject: kthread, tracing: Don't expose half-written comm when creating kthreads
+
+From: Snild Dolkow <snild@sony.com>
+
+commit 3e536e222f2930534c252c1cc7ae799c725c5ff9 upstream.
+
+There is a window for racing when printing directly to task->comm,
+allowing other threads to see a non-terminated string. The vsnprintf
+function fills the buffer, counts the truncated chars, then finally
+writes the \0 at the end.
+
+ creator other
+ vsnprintf:
+ fill (not terminated)
+ count the rest trace_sched_waking(p):
+ ... memcpy(comm, p->comm, TASK_COMM_LEN)
+ write \0
+
+The consequences depend on how 'other' uses the string. In our case,
+it was copied into the tracing system's saved cmdlines, a buffer of
+adjacent TASK_COMM_LEN-byte buffers (note the 'n' where 0 should be):
+
+ crash-arm64> x/1024s savedcmd->saved_cmdlines | grep 'evenk'
+ 0xffffffd5b3818640: "irq/497-pwr_evenkworker/u16:12"
+
+...and a strcpy out of there would cause stack corruption:
+
+ [224761.522292] Kernel panic - not syncing: stack-protector:
+ Kernel stack is corrupted in: ffffff9bf9783c78
+
+ crash-arm64> kbt | grep 'comm\|trace_print_context'
+ #6 0xffffff9bf9783c78 in trace_print_context+0x18c(+396)
+ comm (char [16]) = "irq/497-pwr_even"
+
+ crash-arm64> rd 0xffffffd4d0e17d14 8
+ ffffffd4d0e17d14: 2f71726900000000 5f7277702d373934 ....irq/497-pwr_
+ ffffffd4d0e17d24: 726f776b6e657665 3a3631752f72656b evenkworker/u16:
+ ffffffd4d0e17d34: f9780248ff003231 cede60e0ffffff9b 12..H.x......`..
+ ffffffd4d0e17d44: cede60c8ffffffd4 00000fffffffffd4 .....`..........
+
+The workaround in e09e28671 (use strlcpy in __trace_find_cmdline) was
+likely needed because of this same bug.
+
+Solved by vsnprintf:ing to a local buffer, then using set_task_comm().
+This way, there won't be a window where comm is not terminated.
+
+Link: http://lkml.kernel.org/r/20180726071539.188015-1-snild@sony.com
+
+Cc: stable@vger.kernel.org
+Fixes: bc0c38d139ec7 ("ftrace: latency tracer infrastructure")
+Reviewed-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
+Signed-off-by: Snild Dolkow <snild@sony.com>
+Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ kernel/kthread.c | 8 +++++++-
+ 1 file changed, 7 insertions(+), 1 deletion(-)
+
+--- a/kernel/kthread.c
++++ b/kernel/kthread.c
+@@ -290,8 +290,14 @@ static struct task_struct *__kthread_cre
+ task = create->result;
+ if (!IS_ERR(task)) {
+ static const struct sched_param param = { .sched_priority = 0 };
++ char name[TASK_COMM_LEN];
+
+- vsnprintf(task->comm, sizeof(task->comm), namefmt, args);
++ /*
++ * task is already visible to other tasks, so updating
++ * COMM must be protected.
++ */
++ vsnprintf(name, sizeof(name), namefmt, args);
++ set_task_comm(task, name);
+ /*
+ * root may have changed our (kthreadd's) priority or CPU mask.
+ * The kernel thread should not inherit these properties.
--- /dev/null
+From d97e5e6160c0e0a23963ec198c7cb1c69e6bf9e8 Mon Sep 17 00:00:00 2001
+From: Shakeel Butt <shakeelb@google.com>
+Date: Thu, 26 Jul 2018 16:37:45 -0700
+Subject: kvm, mm: account shadow page tables to kmemcg
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Shakeel Butt <shakeelb@google.com>
+
+commit d97e5e6160c0e0a23963ec198c7cb1c69e6bf9e8 upstream.
+
+The size of kvm's shadow page tables corresponds to the size of the
+guest virtual machines on the system. Large VMs can spend a significant
+amount of memory as shadow page tables which can not be left as system
+memory overhead. So, account shadow page tables to the kmemcg.
+
+[shakeelb@google.com: replace (GFP_KERNEL|__GFP_ACCOUNT) with GFP_KERNEL_ACCOUNT]
+ Link: http://lkml.kernel.org/r/20180629140224.205849-1-shakeelb@google.com
+Link: http://lkml.kernel.org/r/20180627181349.149778-1-shakeelb@google.com
+Signed-off-by: Shakeel Butt <shakeelb@google.com>
+Cc: Michal Hocko <mhocko@kernel.org>
+Cc: Johannes Weiner <hannes@cmpxchg.org>
+Cc: Vladimir Davydov <vdavydov.dev@gmail.com>
+Cc: Paolo Bonzini <pbonzini@redhat.com>
+Cc: Greg Thelen <gthelen@google.com>
+Cc: Radim Krčmář <rkrcmar@redhat.com>
+Cc: Peter Feiner <pfeiner@google.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/kvm/mmu.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/x86/kvm/mmu.c
++++ b/arch/x86/kvm/mmu.c
+@@ -698,7 +698,7 @@ static int mmu_topup_memory_cache_page(s
+ if (cache->nobjs >= min)
+ return 0;
+ while (cache->nobjs < ARRAY_SIZE(cache->objects)) {
+- page = (void *)__get_free_page(GFP_KERNEL);
++ page = (void *)__get_free_page(GFP_KERNEL_ACCOUNT);
+ if (!page)
+ return -ENOMEM;
+ cache->objects[cache->nobjs++] = page;
+input-elan_i2c-add-acpi-id-for-lenovo-ideapad-330.patch
+input-i8042-add-lenovo-lavie-z-to-the-i8042-reset-list.patch
+input-elan_i2c-add-another-acpi-id-for-lenovo-ideapad-330-15ast.patch
+kvm-mm-account-shadow-page-tables-to-kmemcg.patch
+tracing-fix-double-free-of-event_trigger_data.patch
+tracing-fix-possible-double-free-in-event_enable_trigger_func.patch
+kthread-tracing-don-t-expose-half-written-comm-when-creating-kthreads.patch
+tracing-kprobes-fix-trace_probe-flags-on-enable_trace_kprobe-failure.patch
+tracing-quiet-gcc-warning-about-maybe-unused-link-variable.patch
+arm64-fix-vmemmap-build_bug_on-triggering-on-vmemmap-setups.patch
+usb-dwc2-fix-dma-alignment-to-start-at-allocated-boundary.patch
--- /dev/null
+From 1863c387259b629e4ebfb255495f67cd06aa229b Mon Sep 17 00:00:00 2001
+From: "Steven Rostedt (VMware)" <rostedt@goodmis.org>
+Date: Tue, 24 Jul 2018 19:13:31 -0400
+Subject: tracing: Fix double free of event_trigger_data
+
+From: Steven Rostedt (VMware) <rostedt@goodmis.org>
+
+commit 1863c387259b629e4ebfb255495f67cd06aa229b upstream.
+
+Running the following:
+
+ # cd /sys/kernel/debug/tracing
+ # echo 500000 > buffer_size_kb
+[ Or some other number that takes up most of memory ]
+ # echo snapshot > events/sched/sched_switch/trigger
+
+Triggers the following bug:
+
+ ------------[ cut here ]------------
+ kernel BUG at mm/slub.c:296!
+ invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC PTI
+ CPU: 6 PID: 6878 Comm: bash Not tainted 4.18.0-rc6-test+ #1066
+ Hardware name: Hewlett-Packard HP Compaq Pro 6300 SFF/339A, BIOS K01 v03.03 07/14/2016
+ RIP: 0010:kfree+0x16c/0x180
+ Code: 05 41 0f b6 72 51 5b 5d 41 5c 4c 89 d7 e9 ac b3 f8 ff 48 89 d9 48 89 da 41 b8 01 00 00 00 5b 5d 41 5c 4c 89 d6 e9 f4 f3 ff ff <0f> 0b 0f 0b 48 8b 3d d9 d8 f9 00 e9 c1 fe ff ff 0f 1f 40 00 0f 1f
+ RSP: 0018:ffffb654436d3d88 EFLAGS: 00010246
+ RAX: ffff91a9d50f3d80 RBX: ffff91a9d50f3d80 RCX: ffff91a9d50f3d80
+ RDX: 00000000000006a4 RSI: ffff91a9de5a60e0 RDI: ffff91a9d9803500
+ RBP: ffffffff8d267c80 R08: 00000000000260e0 R09: ffffffff8c1a56be
+ R10: fffff0d404543cc0 R11: 0000000000000389 R12: ffffffff8c1a56be
+ R13: ffff91a9d9930e18 R14: ffff91a98c0c2890 R15: ffffffff8d267d00
+ FS: 00007f363ea64700(0000) GS:ffff91a9de580000(0000) knlGS:0000000000000000
+ CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+ CR2: 000055c1cacc8e10 CR3: 00000000d9b46003 CR4: 00000000001606e0
+ Call Trace:
+ event_trigger_callback+0xee/0x1d0
+ event_trigger_write+0xfc/0x1a0
+ __vfs_write+0x33/0x190
+ ? handle_mm_fault+0x115/0x230
+ ? _cond_resched+0x16/0x40
+ vfs_write+0xb0/0x190
+ ksys_write+0x52/0xc0
+ do_syscall_64+0x5a/0x160
+ entry_SYSCALL_64_after_hwframe+0x49/0xbe
+ RIP: 0033:0x7f363e16ab50
+ Code: 73 01 c3 48 8b 0d 38 83 2c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 83 3d 79 db 2c 00 00 75 10 b8 01 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 31 c3 48 83 ec 08 e8 1e e3 01 00 48 89 04 24
+ RSP: 002b:00007fff9a4c6378 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
+ RAX: ffffffffffffffda RBX: 0000000000000009 RCX: 00007f363e16ab50
+ RDX: 0000000000000009 RSI: 000055c1cacc8e10 RDI: 0000000000000001
+ RBP: 000055c1cacc8e10 R08: 00007f363e435740 R09: 00007f363ea64700
+ R10: 0000000000000073 R11: 0000000000000246 R12: 0000000000000009
+ R13: 0000000000000001 R14: 00007f363e4345e0 R15: 00007f363e4303c0
+ Modules linked in: ip6table_filter ip6_tables snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hwdep snd_hda_core snd_seq snd_seq_device i915 snd_pcm snd_timer i2c_i801 snd soundcore i2c_algo_bit drm_kms_helper
+86_pkg_temp_thermal video kvm_intel kvm irqbypass wmi e1000e
+ ---[ end trace d301afa879ddfa25 ]---
+
+The cause is because the register_snapshot_trigger() call failed to
+allocate the snapshot buffer, and then called unregister_trigger()
+which freed the data that was passed to it. Then on return to the
+function that called register_snapshot_trigger(), as it sees it
+failed to register, it frees the trigger_data again and causes
+a double free.
+
+By calling event_trigger_init() on the trigger_data (which only ups
+the reference counter for it), and then event_trigger_free() afterward,
+the trigger_data would not get freed by the registering trigger function
+as it would only up and lower the ref count for it. If the register
+trigger function fails, then the event_trigger_free() called after it
+will free the trigger data normally.
+
+Link: http://lkml.kernel.org/r/20180724191331.738eb819@gandalf.local.home
+
+Cc: stable@vger.kerne.org
+Fixes: 93e31ffbf417 ("tracing: Add 'snapshot' event trigger command")
+Reported-by: Masami Hiramatsu <mhiramat@kernel.org>
+Reviewed-by: Masami Hiramatsu <mhiramat@kernel.org>
+Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ kernel/trace/trace_events_trigger.c | 12 ++++++++----
+ 1 file changed, 8 insertions(+), 4 deletions(-)
+
+--- a/kernel/trace/trace_events_trigger.c
++++ b/kernel/trace/trace_events_trigger.c
+@@ -678,6 +678,8 @@ event_trigger_callback(struct event_comm
+ goto out_free;
+
+ out_reg:
++ /* Up the trigger_data count to make sure reg doesn't free it on failure */
++ event_trigger_init(trigger_ops, trigger_data);
+ ret = cmd_ops->reg(glob, trigger_ops, trigger_data, file);
+ /*
+ * The above returns on success the # of functions enabled,
+@@ -685,11 +687,13 @@ event_trigger_callback(struct event_comm
+ * Consider no functions a failure too.
+ */
+ if (!ret) {
++ cmd_ops->unreg(glob, trigger_ops, trigger_data, file);
+ ret = -ENOENT;
+- goto out_free;
+- } else if (ret < 0)
+- goto out_free;
+- ret = 0;
++ } else if (ret > 0)
++ ret = 0;
++
++ /* Down the counter of trigger_data or free it if not used anymore */
++ event_trigger_free(trigger_ops, trigger_data);
+ out:
+ return ret;
+
--- /dev/null
+From 15cc78644d0075e76d59476a4467e7143860f660 Mon Sep 17 00:00:00 2001
+From: "Steven Rostedt (VMware)" <rostedt@goodmis.org>
+Date: Wed, 25 Jul 2018 16:02:06 -0400
+Subject: tracing: Fix possible double free in event_enable_trigger_func()
+
+From: Steven Rostedt (VMware) <rostedt@goodmis.org>
+
+commit 15cc78644d0075e76d59476a4467e7143860f660 upstream.
+
+There was a case that triggered a double free in event_trigger_callback()
+due to the called reg() function freeing the trigger_data and then it
+getting freed again by the error return by the caller. The solution there
+was to up the trigger_data ref count.
+
+Code inspection found that event_enable_trigger_func() has the same issue,
+but is not as easy to trigger (requires harder to trigger failures). It
+needs to be solved slightly different as it needs more to clean up when the
+reg() function fails.
+
+Link: http://lkml.kernel.org/r/20180725124008.7008e586@gandalf.local.home
+
+Cc: stable@vger.kernel.org
+Fixes: 7862ad1846e99 ("tracing: Add 'enable_event' and 'disable_event' event trigger commands")
+Reivewed-by: Masami Hiramatsu <mhiramat@kernel.org>
+Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ kernel/trace/trace_events_trigger.c | 6 +++++-
+ 1 file changed, 5 insertions(+), 1 deletion(-)
+
+--- a/kernel/trace/trace_events_trigger.c
++++ b/kernel/trace/trace_events_trigger.c
+@@ -1389,6 +1389,9 @@ int event_enable_trigger_func(struct eve
+ goto out;
+ }
+
++ /* Up the trigger_data count to make sure nothing frees it on failure */
++ event_trigger_init(trigger_ops, trigger_data);
++
+ if (trigger) {
+ number = strsep(&trigger, ":");
+
+@@ -1439,6 +1442,7 @@ int event_enable_trigger_func(struct eve
+ goto out_disable;
+ /* Just return zero, not the number of enabled functions */
+ ret = 0;
++ event_trigger_free(trigger_ops, trigger_data);
+ out:
+ return ret;
+
+@@ -1449,7 +1453,7 @@ int event_enable_trigger_func(struct eve
+ out_free:
+ if (cmd_ops->set_filter)
+ cmd_ops->set_filter(NULL, trigger_data, NULL);
+- kfree(trigger_data);
++ event_trigger_free(trigger_ops, trigger_data);
+ kfree(enable_data);
+ goto out;
+ }
--- /dev/null
+From 57ea2a34adf40f3a6e88409aafcf803b8945619a Mon Sep 17 00:00:00 2001
+From: Artem Savkov <asavkov@redhat.com>
+Date: Wed, 25 Jul 2018 16:20:38 +0200
+Subject: tracing/kprobes: Fix trace_probe flags on enable_trace_kprobe() failure
+
+From: Artem Savkov <asavkov@redhat.com>
+
+commit 57ea2a34adf40f3a6e88409aafcf803b8945619a upstream.
+
+If enable_trace_kprobe fails to enable the probe in enable_k(ret)probe
+it returns an error, but does not unset the tp flags it set previously.
+This results in a probe being considered enabled and failures like being
+unable to remove the probe through kprobe_events file since probes_open()
+expects every probe to be disabled.
+
+Link: http://lkml.kernel.org/r/20180725102826.8300-1-asavkov@redhat.com
+Link: http://lkml.kernel.org/r/20180725142038.4765-1-asavkov@redhat.com
+
+Cc: Ingo Molnar <mingo@redhat.com>
+Cc: stable@vger.kernel.org
+Fixes: 41a7dd420c57 ("tracing/kprobes: Support ftrace_event_file base multibuffer")
+Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
+Reviewed-by: Josh Poimboeuf <jpoimboe@redhat.com>
+Signed-off-by: Artem Savkov <asavkov@redhat.com>
+Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ kernel/trace/trace_kprobe.c | 13 +++++++++++--
+ 1 file changed, 11 insertions(+), 2 deletions(-)
+
+--- a/kernel/trace/trace_kprobe.c
++++ b/kernel/trace/trace_kprobe.c
+@@ -359,11 +359,10 @@ static struct trace_kprobe *find_trace_k
+ static int
+ enable_trace_kprobe(struct trace_kprobe *tk, struct trace_event_file *file)
+ {
++ struct event_file_link *link;
+ int ret = 0;
+
+ if (file) {
+- struct event_file_link *link;
+-
+ link = kmalloc(sizeof(*link), GFP_KERNEL);
+ if (!link) {
+ ret = -ENOMEM;
+@@ -383,6 +382,16 @@ enable_trace_kprobe(struct trace_kprobe
+ else
+ ret = enable_kprobe(&tk->rp.kp);
+ }
++
++ if (ret) {
++ if (file) {
++ list_del_rcu(&link->list);
++ kfree(link);
++ tk->tp.flags &= ~TP_FLAG_TRACE;
++ } else {
++ tk->tp.flags &= ~TP_FLAG_PROFILE;
++ }
++ }
+ out:
+ return ret;
+ }
--- /dev/null
+From 2519c1bbe38d7acacc9aacba303ca6f97482ed53 Mon Sep 17 00:00:00 2001
+From: "Steven Rostedt (VMware)" <rostedt@goodmis.org>
+Date: Wed, 25 Jul 2018 22:28:56 -0400
+Subject: tracing: Quiet gcc warning about maybe unused link variable
+
+From: Steven Rostedt (VMware) <rostedt@goodmis.org>
+
+commit 2519c1bbe38d7acacc9aacba303ca6f97482ed53 upstream.
+
+Commit 57ea2a34adf4 ("tracing/kprobes: Fix trace_probe flags on
+enable_trace_kprobe() failure") added an if statement that depends on another
+if statement that gcc doesn't see will initialize the "link" variable and
+gives the warning:
+
+ "warning: 'link' may be used uninitialized in this function"
+
+It is really a false positive, but to quiet the warning, and also to make
+sure that it never actually is used uninitialized, initialize the "link"
+variable to NULL and add an if (!WARN_ON_ONCE(!link)) where the compiler
+thinks it could be used uninitialized.
+
+Cc: stable@vger.kernel.org
+Fixes: 57ea2a34adf4 ("tracing/kprobes: Fix trace_probe flags on enable_trace_kprobe() failure")
+Reported-by: kbuild test robot <lkp@intel.com>
+Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ kernel/trace/trace_kprobe.c | 6 ++++--
+ 1 file changed, 4 insertions(+), 2 deletions(-)
+
+--- a/kernel/trace/trace_kprobe.c
++++ b/kernel/trace/trace_kprobe.c
+@@ -359,7 +359,7 @@ static struct trace_kprobe *find_trace_k
+ static int
+ enable_trace_kprobe(struct trace_kprobe *tk, struct trace_event_file *file)
+ {
+- struct event_file_link *link;
++ struct event_file_link *link = NULL;
+ int ret = 0;
+
+ if (file) {
+@@ -385,7 +385,9 @@ enable_trace_kprobe(struct trace_kprobe
+
+ if (ret) {
+ if (file) {
+- list_del_rcu(&link->list);
++ /* Notice the if is true on not WARN() */
++ if (!WARN_ON_ONCE(!link))
++ list_del_rcu(&link->list);
+ kfree(link);
+ tk->tp.flags &= ~TP_FLAG_TRACE;
+ } else {
--- /dev/null
+From 56406e017a883b54b339207b230f85599f4d70ae Mon Sep 17 00:00:00 2001
+From: Antti Seppälä <a.seppala@gmail.com>
+Date: Thu, 5 Jul 2018 17:31:53 +0300
+Subject: usb: dwc2: Fix DMA alignment to start at allocated boundary
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Antti Seppälä <a.seppala@gmail.com>
+
+commit 56406e017a883b54b339207b230f85599f4d70ae upstream.
+
+The commit 3bc04e28a030 ("usb: dwc2: host: Get aligned DMA in a more
+supported way") introduced a common way to align DMA allocations.
+The code in the commit aligns the struct dma_aligned_buffer but the
+actual DMA address pointed by data[0] gets aligned to an offset from
+the allocated boundary by the kmalloc_ptr and the old_xfer_buffer
+pointers.
+
+This is against the recommendation in Documentation/DMA-API.txt which
+states:
+
+ Therefore, it is recommended that driver writers who don't take
+ special care to determine the cache line size at run time only map
+ virtual regions that begin and end on page boundaries (which are
+ guaranteed also to be cache line boundaries).
+
+The effect of this is that architectures with non-coherent DMA caches
+may run into memory corruption or kernel crashes with Unhandled
+kernel unaligned accesses exceptions.
+
+Fix the alignment by positioning the DMA area in front of the allocation
+and use memory at the end of the area for storing the orginal
+transfer_buffer pointer. This may have the added benefit of increased
+performance as the DMA area is now fully aligned on all architectures.
+
+Tested with Lantiq xRX200 (MIPS) and RPi Model B Rev 2 (ARM).
+
+Fixes: 3bc04e28a030 ("usb: dwc2: host: Get aligned DMA in a more supported way")
+Cc: <stable@vger.kernel.org>
+Reviewed-by: Douglas Anderson <dianders@chromium.org>
+[ Antti: backported to 4.9: edited difference in whitespace ]
+Signed-off-by: Antti Seppälä <a.seppala@gmail.com>
+Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/dwc2/hcd.c | 44 +++++++++++++++++++++++---------------------
+ 1 file changed, 23 insertions(+), 21 deletions(-)
+
+--- a/drivers/usb/dwc2/hcd.c
++++ b/drivers/usb/dwc2/hcd.c
+@@ -2544,34 +2544,29 @@ static void dwc2_hc_init_xfer(struct dwc
+
+ #define DWC2_USB_DMA_ALIGN 4
+
+-struct dma_aligned_buffer {
+- void *kmalloc_ptr;
+- void *old_xfer_buffer;
+- u8 data[0];
+-};
+-
+ static void dwc2_free_dma_aligned_buffer(struct urb *urb)
+ {
+- struct dma_aligned_buffer *temp;
++ void *stored_xfer_buffer;
+
+ if (!(urb->transfer_flags & URB_ALIGNED_TEMP_BUFFER))
+ return;
+
+- temp = container_of(urb->transfer_buffer,
+- struct dma_aligned_buffer, data);
++ /* Restore urb->transfer_buffer from the end of the allocated area */
++ memcpy(&stored_xfer_buffer, urb->transfer_buffer +
++ urb->transfer_buffer_length, sizeof(urb->transfer_buffer));
+
+ if (usb_urb_dir_in(urb))
+- memcpy(temp->old_xfer_buffer, temp->data,
++ memcpy(stored_xfer_buffer, urb->transfer_buffer,
+ urb->transfer_buffer_length);
+- urb->transfer_buffer = temp->old_xfer_buffer;
+- kfree(temp->kmalloc_ptr);
++ kfree(urb->transfer_buffer);
++ urb->transfer_buffer = stored_xfer_buffer;
+
+ urb->transfer_flags &= ~URB_ALIGNED_TEMP_BUFFER;
+ }
+
+ static int dwc2_alloc_dma_aligned_buffer(struct urb *urb, gfp_t mem_flags)
+ {
+- struct dma_aligned_buffer *temp, *kmalloc_ptr;
++ void *kmalloc_ptr;
+ size_t kmalloc_size;
+
+ if (urb->num_sgs || urb->sg ||
+@@ -2579,22 +2574,29 @@ static int dwc2_alloc_dma_aligned_buffer
+ !((uintptr_t)urb->transfer_buffer & (DWC2_USB_DMA_ALIGN - 1)))
+ return 0;
+
+- /* Allocate a buffer with enough padding for alignment */
++ /*
++ * Allocate a buffer with enough padding for original transfer_buffer
++ * pointer. This allocation is guaranteed to be aligned properly for
++ * DMA
++ */
+ kmalloc_size = urb->transfer_buffer_length +
+- sizeof(struct dma_aligned_buffer) + DWC2_USB_DMA_ALIGN - 1;
++ sizeof(urb->transfer_buffer);
+
+ kmalloc_ptr = kmalloc(kmalloc_size, mem_flags);
+ if (!kmalloc_ptr)
+ return -ENOMEM;
+
+- /* Position our struct dma_aligned_buffer such that data is aligned */
+- temp = PTR_ALIGN(kmalloc_ptr + 1, DWC2_USB_DMA_ALIGN) - 1;
+- temp->kmalloc_ptr = kmalloc_ptr;
+- temp->old_xfer_buffer = urb->transfer_buffer;
++ /*
++ * Position value of original urb->transfer_buffer pointer to the end
++ * of allocation for later referencing
++ */
++ memcpy(kmalloc_ptr + urb->transfer_buffer_length,
++ &urb->transfer_buffer, sizeof(urb->transfer_buffer));
++
+ if (usb_urb_dir_out(urb))
+- memcpy(temp->data, urb->transfer_buffer,
++ memcpy(kmalloc_ptr, urb->transfer_buffer,
+ urb->transfer_buffer_length);
+- urb->transfer_buffer = temp->data;
++ urb->transfer_buffer = kmalloc_ptr;
+
+ urb->transfer_flags |= URB_ALIGNED_TEMP_BUFFER;
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
